Real-time control system development tool

ABSTRACT

A composite object group (COG) data structure embodied in a computer-readable medium for building a control system that has both a clock cycle and event processing is provided. An interface for passing information to and from the COG data structure is provided. One or more data flow objects are provided in the COG to accept input data and to produce output data on the clock cycle. The data flow object is connected to the interface and provides sampled-data processing for the control system. One or more state machine objects are provided in the COG; each includes a plurality of states and a plurality of transitions between the states that are each triggered by an event. The state machine object provides event-driven processing for the control system, whereby the COG data structure provides both sampled-data and event-driven processing for the control system.

This application is a divisional of U.S. patent application Ser. No.09/259,179 now U.S. Pat. No. 6,718,533, filed Feb. 26, 1999 entitled“Real-time Control System Development Tool,” which is herebyincorporated by reference.

This application is related to U.S. patent application Ser. No.10/207,430, filed on the same date herewith, having the same title,which is hereby incorporated by reference.

This invention was partially funded under National Institute ofStandards and Technology (NIST) Advanced Technology Program (ATP)contract No. 70NANB5H1163. The government has certain rights in thisinvention.

FIELD OF THE INVENTION

The present invention relates generally to a programming tool forsoftware development. More specifically, the present invention relatesto a tool for developing and executing real-time control systems.

BACKGROUND OF THE INVENTION

Real-time system software is notoriously complex. Large projects mustbalance the special needs of real-time software—such as eventprocessing, data sampling, and feedback control—with the needs ofinteracting teams of programmers, engineers, managers, and maintenancepersonnel. Successful projects require solid software architecture, anintuitive, graphical programming paradigm, and a well-developed reusecapability.

Building software for real-time control systems is a huge challenge. Thesoftware must coordinate actuators, sensors, and interactions with thereal world. It must deal with complex and intelligent subsystems. Manysystems are large applications developed by teams of programmers,engineers, architects, and managers. All team members must be able toboth understand and contribute to the design. The demands for a modular,clean design are compounded by the special needs of control systems suchas control and sequencing. Systems are built, simulated and testedincrementally for best results. Significant legacy code embodying yearsof experience is often required to be used. In the past, these controlsystems defied reorganization. Prior art development tools for suchcomplex systems have simply not been able to keep pace with the demandsof these complex systems.

Development tools built for other real-time applications—such astelecommunications or databases—are not well suited to the challenges ofcomplex control systems. In particular, they are not well-suited forcomplex electromechanical systems. Generic programming languages andmethodologies are useful for modeling. They carefully define the nuancesof syntax and meta language. But often they do not truly acceleratedevelopment. In particular, prior art object-oriented modeling tools areuseful for some systems as will be described below, but are not wellsuited for the needs of complex, real-time control systems.

Prior art mathematical simulation tools can also be useful. They allowyou to build and test dynamic models of the physical processes in yoursystem. However, in most systems they only apply to a small percentageof the total problem. They are not good programming systems, and thuscannot handle truly complex systems that require significant customcoding. In particular, mathematical simulation tools are useful forcertain applications as will be described below, but are also notespecially well-suited for the needs of complex, real-time controlsystems.

In general, two approaches have been used in the prior art to developcomplex software systems: top-down design and bottom-up design. Top-downdesign means breaking the problem into smaller and smaller parts untilthe pieces can be implemented easily. Top-down design is very generaland powerful; it can eventually solve most problems. It is alsointuitive, it allows division of labor, and it encourages rapidprototyping through consideration of intermediate incomplete models of acomplex system. It provides a high level view important to communicationand understanding between team members and management.

Most people naturally think of complex systems in a top-down,object-oriented fashion. For instance, when you describe a car, youthink of the engine, the frame, the transmission, and other systems asfunctional, complete objects that cooperate to make the whole complexsystem. However, the top-down design process has a serious flaw: itleads to unique solutions to every problem. Each top-down designsubdivides the problem in a unique way. None of the resulting subsystemscan be reused easily. A top-down design has been called “the process ofmaking all your worst mistakes first.” A top-down designer building acar would start with a concept drawing, and break it into subsystems asbest fit the problem. However, like a concept car, the result willcontain many strange parts that all have to be painstakinglyhandcrafted.

Often, prior art object-oriented modeling tools are thought of asproviding a top-down design approach because they provide an objectmodel view of the world. In particular, various prior art objectmodeling tools work well for general problem areas, but are not optimalfor complex, real-time control systems. For example, one object modelingtool available from Rational Corporation of Sunnyvale, Calif. is called“Rose.” Rose is based on the well-known Unified Language Modeling (UML)graphical development tool (a general tool). Rose provides event-drivenprocessing for general problem areas. Another UML-based tool is“Rhapsody,” available from iLogix Corporation of Andover, Mass. thatalso addresses general problem areas. Another representative objectmodeling tool is “ObjecTime,” available from ObjectTime of Ottawa,Canada. ObjecTime is based on the real-time object-oriented modeling(ROOM) language and is especially suited for modeling telecommunicationssystems.

In general, these prior art object modeling tools are based primarily onevent-driven processing because of the problems to which they areaddressed. They are not well-suited for, and are unable to handle,sampled-data processing mainly because the problems they address do notrequire it. In general, these prior art object modeling tools do notprovide sampled-data processing that is often critical in complexreal-time systems. Specifically, these tools have no concept of matricesand are unable to implement detailed mathematical calculations norevolve over time. These deficiencies mean that these tools may not bewell-suited for certain real-time systems that require such complexmathematical simulations.

At the other end of the spectrum are bottom-up design tools. Bottom-updesign is the process of synthesizing from preexisting components. Abottom-up design process for building a car would be to walk into anauto parts store and begin piecing together the vehicle from parts onthe rack. Bottom-up design is great for reusing such parts. However,without the overall picture and goal in mind, it often does not resultin a clean division of functionality. The bottom-up design processprovides no overall view to communicate the goals and progress of aproject between team members. Bottom-up design is important for reuse,however, and to achieve true leverage, software must be reusedunmodified. By contrast, copying and modifying code creates many sourceversions that must be independently tested and maintained. Only truereuse generates the leverage that results in large dividends.

To be truly powerful, bottom-up design should support multiple levels ofgranularity. Small, functional components are easy to reuse, but do notprovide large benefits. On the other hand, large-scale componentsprovide large-scale benefits. The reuse of an entire subsystem as acomponent would accelerate greatly the next system's implementation. Butcomplex components have complex interfaces and specific functions. Themore complex the component, the harder it is to reuse. Clearly, tomaximize the benefits of component-based design, components should bereusable at different levels.

Many of the prior art mathematical simulation tools often are thought ofas providing a bottom-up design. As such, they provide advantages forcertain narrow problem areas, but are not well-suited for modelingcomplex real-time systems. One simulation tool is “Simulink,” availablefrom Math Works of Natick, Mass. Another simulation tool is “SystemBuild,” available from Integrated Systems, Inc. of Sunnyvale, Calif.These prior art simulation tools (and others) are based upon amathematical model of the world and use complex matrix libraries tosimulate a model using matrices. These tools are useful for simulatingcomplex processes over time where complex calculations are involved.These tools typically provide sampled-data processing that can simulatea system and evolve over time.

These simulation tools, however, are not object-oriented programmingtools and are not well-suited for modeling systems or for buildingcomplex real-time systems. Specifically, these tools are useful forbuilding a data flow model of the world where intense number crunchingis necessary, but they do not provide objects, methods upon objects, orthe other beneficial features of object-oriented programming tools.

Unfortunately, often complex problems require both a top-down and abottom-up approach. The two approaches are very different and requirefundamentally different thought processes. Complex, real-time systems(and electromechanical systems in particular) may have a need for bothdata-flow processing as well as specific reactions to discrete events.

Therefore, a method and apparatus are desired that would provide theadvantages of both top-down and bottom-up design for real-time controlsystems. Further, a method and apparatus are desired that would providethe object-oriented and event-driven capabilities of object-orientedmodeling tools with the matrix manipulation and sampled-data processingfeatures of mathematical simulation tools.

Another area of intelligent control that could benefit from improvementis the management of modes. Most complex systems require differentoperating modes. To illustrate, consider the simple example of a hybridautomobile powered by both gasoline and electricity. The car has bothbatteries and gasoline for use as fuel, and both an electric motor and agasoline engine for propulsion. The car can be operated in two modes. Inthe zero-emission mode, the car uses the electric motor and thebatteries. In the low-emission mode, the car uses the gasoline engineand the gasoline. Of course, real-life control systems are incrediblymore complex.

Some prior art systems attempt to implement modes informally usingad-hoc implementation of “if-then-else” statements. This technique isconfusing and hard to understand and maintain. Other systems use special“switch blocks” that run control lines to every other block within thesystem. These lines can become very complex and difficult to manage, letalone simply trying to figure out which mode the system is in.Furthermore, many complex systems often radically change modes ofoperation during execution. The designs of these systems may fail toconsider the wide-ranging effects of these mode changes and “run out ofsteam” due to the complexity of the branches and switch blocks required.A fundamentally new approach to the management of modes would bedesirable.

Another area of intelligent control that could benefit from improvementis the creation of executable programs for different purposes. Often auser will create a complex control system and its correspondingexecutable image to run on a specific real-time computer. The user,however, may wish to simulate the system on his or her own desktopcomputer. It can be time-consuming and complex to redo the system tomake a simulation. Certain components only applicable to the real-timecomputer might have to be removed and substituted with simulationcomponents.

Another area of intelligent control that could benefit from improvementis the optimal utilization of processing resources. Often differentelements within a control system might need to run at different rates.The fast rate required for a particular sensor may be incompatible withthe slower sampling rate of a different element. Simply slowing thewhole system down to accommodate one slow rate element is not efficient.Conversely, speeding up the whole system to run at a fast rate is notfeasible if one particular sensor or data sampling element cannot cyclethat quickly. Further, it can be unwieldy to break the system intodifferent pieces for different processors, only to try to cobble thesystem back together to make it function correctly. It would bedesirable to take advantage of numerous processors and/or multiplethreads of execution that may be provided by a real-time computer.

SUMMARY OF THE INVENTION

To achieve the foregoing, and in accordance with the purpose of thepresent invention, a development tool is disclosed that combines theadvantages of a simulation tool with an object-oriented modeling tool.An embodiment of the present invention is based on a real-timemathematical matrix library, but also has an object model.Advantageously, most all real-time systems can be modeled using thepresent invention. The present invention supports the entire process forbuilding complex real-time systems: design; development; execution;test; and maintenance. The present invention is well-suited for systemsthat have complex interactions, require strategic decisions, usecontrol, have intelligent subsystems, and/or exhibit modal behavior.

In general, the present invention is applicable to any intelligentcontrol system. In particular, the present invention is advantageous fordeveloping software for real-time electromechanical systems. Forexample, the present invention is applicable to aerospace systems,robotics, autonomous vehicles, hardware-in-the-loop (HIL) test,semiconductor manufacturing equipment, and many other types of complexelectromechanical systems. Nevertheless, the present invention is not tobe limited to electromechanical systems, but can also be used for signalprocessing, process control, medical imaging, radar control, etc.

Advantageously, the present invention realizes that many real-timesystems (and electromechanical systems in particular) have two verydifferent aspects: continuous data flow and event-driven reaction. Thesetwo aspects are common to most complex systems, and in particular arefundamental in electromechanical systems. It is observed that in complexelectromechanical applications, sampled-data processing and event-drivenprocessing are tightly integrated. In fact, most real-time applicationscan be divided into recognizable subsystems that include bothsampled-data and event-driven processing. For instance, a robotic systemhas subsystems for the arm, gripper, and vision. Each processes datacontinuously (i.e., cyclically samples data) but also executes sequenceswhen events are detected.

One embodiment of the invention codifies this observed structure. Thepresent invention introduces the concept of a composite object group, or“COG”. A COG is an object that may contain both sampled-data andevent-driven capabilities. COGs are extremely powerful in that they areintuitive, they merge procedural and object-oriented programming, andare they well-suited for implementing intelligent control systems. A COGprovides explicit, graphical integration of both types of processing andare fully hierarchical. That is, you can design complex systems bybuilding COGs made up of other COGs. A COG may also contain a thirdaspect, an interface. An interface specifies both the data flow throughthe COG and the set of methods the COG provides (implements) and uses.

In addition to combining event-driven and sampled-data processing, COGsare also able to bridge procedural and object-oriented design. Bothevent-driven and continuous data applications are most naturally thoughtof as occurring procedurally. Control engineers are used to thinking inthis manner; control systems are built from blocks that process inputsand produce outputs. On the other hand, larger subsystems are most oftenbest modeled as objects. Objects are usually thought of as executingindependently of and concurrently with other objects. They communicateby exchanging asynchronous messages. Object-oriented design isfundamentally different than procedural thinking. As a COG is an objectthat is built from procedural components, it neatly bridges the gapbetween procedural thinking (more efficient at low engineering levels)and powerful object-oriented thinking (more efficient at higher systemdesign levels).

Prior art modeling languages, such as C++ and UML, provide a means ofdescribing arbitrary relationships between various objects for attackinggeneral problem domains. Each object can contain arbitraryfunctionality. UML, for example, is an object-oriented graphicalnotation that is a very general modeling language. It is used foreverything from airline reservation transaction systems to cellulartelephone firmware. UML's first primary function is analysis—the processof examining a problem and designing a structure that can solve theproblem. This is a top-down approach. Each problem leads to a uniquestructure.

By contrast, the present invention uses COGs to model complex real-timesystems, and in particular is well-suited for modeling electromechanicalsystems. This utilization of a specific object model bestows manybenefits. For instance, it shortcuts much of the tedious analysis andobject hierarchy design phase. The present invention provides specificdata structures and reusable objects that fit specific problem domains.It allows problems to be modeled faster and complex code to be workingmore quickly. In addition, the present invention is not limited toproviding only a top-down design approach as in UML.

Recognizing the tradeoff between top-down and bottom-up design, thepresent invention takes a unique merged approach. Top-down objectdecomposition is combined with bottom-up component-based synthesis fromreusable software. This combined approach couples object-oriented designwith the power of building systems from tested, preexisting softwarecomponents. It uses an intuitive approach to developing systems thatmatch how most engineers naturally design. Initially, a global,undefined concept is decomposed into more specialized subsystems (ormodules). Along the way, reusable objects are defined and incorporatedthat ensure clean divisions between subsystems. Finally, subsystems arebuilt from the bottom-up by graphically combining components from arepository of reusable software. This merged approach combines the powerof object modeling with the leverage of component-based synthesis.

This top-down/bottom-up combined approach is very intuitive. It allowsdesigners to work simultaneously at different levels ofabstraction-today on the overall design, tomorrow on a specificsubsystem. This makes it easy to iterate between partially-specifieddesigns and fully-specified subsystems. In one aspect of the invention,interfaces are defined between subsystems during top-down decomposition.As long as the interfaces are unique, top-down decomposition continues.When the design is refined to the point that existing components can beused, these components are then used to fill in the functionalityneeded. Thus, design may begin from the top-down, but eventuallycommonly defined components are reached during the process. Prior arttools have provided no mechanism for this combined design to occur.

The present invention also provides a technique by which a commonly usedobject interface may be defined as a reusable object. Thus, a mechanismfor both defining and reusing interfaces is provided, makingstandardized interfaces are possible. Over time within a project, anorganization, or even a market, these interfaces allow component-baseddesign. Because these interfaces can be attached to many differentsoftware objects, they provide a layer of abstraction between theexternal behavior of an object and its implementation.

The present invention also provides a technique for “mapping” thecomputing resources of a computing device throughout the hierarchy of acontrol system. Mapping is provided for modes, executable programs andthreads of a processor.

Under mode mapping, the user is allowed to choose in a simple andintuitive manner which components of the control system will run inwhich mode. Each component may have a number of modes, each identifiedby a name. For a group of components (e.g. a control system for a robotarm), a mode may be defined for this whole group by picking and choosingdesirable modes for the components contained within. Thus, for a givenmode for the whole system, only selected components are “active” andwill run. This allows a user to choose at high level which code will beallowed to run for a given situation.

Using executable mapping, the user chooses on which processor componentswill run. Users may build multiple executable programs from a singlesystem diagram. Multiple executables are desirable should the user wishto create one executable for the actual hardware real-time computer, andanother executable for simulation on the user's own computer. Withexecutable mapping, the user can create an executable for each situationby choosing which components are to be run in which situation. In otherwords, an individual processor can be chosen on which to run eachcomponent simply by naming an executable for each component.

Within a given processor, each component of a control system may beassigned to individual execution threads within that processor simply bynaming a thread. Each thread may be configured to execute at a differentrate, thus providing different rates of executions for differentcomponents within one control system. Also a composite component such asa composite object group or a finite state machine may be assigned tomultiple threads to accommodate the different needs of its constituentcomponents. Each component in the hierarchy of a system diagram isassigned a logical rate that is eventually mapped to an actual rate of athread. In this way, a component with its hierarchy of logical rates isreusable and may be inserted into a different real-time system thatmight have different threads and rates available. When used in this way,the logical rates of a component are simply mapped to whatever actualrates that are available (which may number greater or fewer than thelogical rates); each lower-level component is thus assigned to an actualrate.

Thus, mechanisms for specifying and changing the modes of operation of acontrol system are provided, for assigning portions of the system to beembodied into different executable images, and for assigning portions ofan executable image to be executed by different operating system threadsof a processor. These mechanisms provide a named layer of abstractionbetween hierarchical levels, and thus allow each hierarchical level tobe more self-contained. Prior art systems instead utilize “if”statements or control lines and switch blocks, and are thus more poorlystructured. These three types of mapping, modes, executables andthreads, may exist independently of one another, or may be combined withone another in a single control system.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may best be understood by reference to the followingdescription taken in conjunction with the accompanying drawings inwhich:

FIG. 1 is a pyramid symbolizing the power versus generality tradeoff inprogramming languages.

FIG. 2 illustrates an example of a real-time application according toone embodiment of the present invention.

FIG. 3 illustrates symbolically the makeup of a real-time computer.

FIG. 4 illustrates symbolically a data flow component.

FIG. 5 illustrates symbolically a state transition component.

FIG. 6A shows symbolically a state transition component in communicationwith a data flow component.

FIG. 6B illustrates in greater detail how a state transition componentcalls a method of a data flow component.

FIG. 6C illustrates in greater detail how a method of a data flowcomponent calls an internal method.

FIG. 7 illustrates symbolically a state machine component.

FIG. 8 illustrates symbolically an interface component.

FIG. 9 illustrates symbolically a composite object group (COG)component.

FIG. 10 illustrates graphically a programming process and the roles thatvarious individuals may play in creating a control system.

FIG. 11A illustrates a programming process for producing a real-timeintelligent control system.

FIG. 11B illustrates in greater detail an embodiment for a repository.

FIG. 12 illustrates a methodology for creating a robot control system.

FIG. 13 illustrates a methodology for creating a reaction controlsystem.

FIG. 14 illustrates a very simplistic robot arm controller that providesa simple example of a composite object group (COG) and of variousinterfaces.

FIG. 15 is a textual representation of an interface for a trajectorygenerator.

FIG. 16 is a textual representation of an interface for a PD controller.

FIG. 17 is a textual representation of an interface for an intelligentcontroller COG.

FIG. 18 is a flowchart describing one embodiment of the life cycle foran intelligent control system.

FIG. 19 is a flowchart describing one embodiment for the create systemdiagram step 606 of FIG. 18.

FIG. 20 is a flowchart describing one embodiment for the linking phasestep 612 of FIG. 18.

FIG. 21 is a flowchart describing one embodiment for the implementationof initialization phase step 614 of FIG. 18.

FIG. 22 is a flowchart describing one embodiment for data flow run-timeengine execution of FIG. 18.

FIG. 23 is a flowchart describing one embodiment of the state machinerun-time engine of FIG. 18.

FIG. 24 illustrates a system of seven data flow components having twooperating modes.

FIG. 25 illustrates a system of COGs each having various modes.

FIG. 26 illustrates mapping of threads in a simple one-level systemhaving two rates of execution.

FIG. 27 illustrates mapping of threads in a more complex system havingtwo rates of execution and a hierarchy or components.

FIG. 28 illustrates mapping of components to executable programs.

FIG. 29 illustrates an intelligent control system having two executableprograms.

FIGS. 30 and 31 illustrate a computer system 900 suitable forimplementing embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Real-time software for control systems is complex. There are excellentcontrol and simulation tools, but often they do not address the complexprogramming needs of many systems. There are general programming tools,but often they do not provide useful facilities for real-time controlproblems. What is missing is a programming tool with prebuiltarchitectures designed specifically for real-time control problems.Although the present invention is suitable for use with a wide range ofintelligent control applications, real-time electromechanical systems inparticular will often be highlighted in the course of this disclosure toprovide a working example.

Control systems may be complex because of the mathematical algorithmsthey contain, or because they contain many concurrent elements. Forexample, electromechanical systems exhibit both of these types ofcomplexity to some extent, but more importantly are faced withcomputational structure complexity. Electromechanical systems must makestrategic decisions, communicate with complex intelligent modules anduser interfaces, process data, execute feedback loops, change modes, anddrive complex hardware. Interconnecting these subsystems leads to evenmore structural complexity. Many systems must also be modal, changingbehavior in response to changes in operating conditions. Modal behaviorcan add very significant—and often unforeseen—structural complexity.Structural complexity dominates most electromechanical systems.

Because it is difficult to handle all types of complexity, programminglanguages often make choices based on their target systems. Thedevelopment tool of the present invention provides facilities to addressstructural complexity and also recognizes the duality of sampled-dataand event-driven processing. The resulting tool is simple, powerful andmaps directly to intelligent control problems.

Overview and High Level Diagram

FIG. 1 is a pyramid 1 symbolizing the power versus generality tradeoffin programming languages. There is a tradeoff between power andgenerality in any implementation technique. Theoretically, eachapplication problem should use the least general—and therefore the mostpowerful—programming language that solves its particular problem. Forexample, the first level 2 of the pyramid representing assembly languageis quite broad because it symbolizes that virtually any softwareapplication could be written in assembly language. In other words,assembly language is very general, but not extremely powerful for anygiven application because it has little structure. Assembly language isespecially suited for applications such as device drivers. Level 4represents the C programming language that is suitable for writing anapplication such as a function library. While slightly less general thanassembly language, the C programming language is more powerful.

In a similar fashion, the C++ and object-oriented programming languagesrepresented in level 6 are even more powerful because of the objectconcepts they introduce. These languages are suited for implementing acompiler for example. Level 8 represents the class of object modelinglanguages and is quite narrow, indicating that it is suitable fornarrower classes of applications such as airline reservation systems,databases, and other complex systems. The Unified Modeling Language(UML) is one such language.

At the top of the pyramid is the development tool 10 of the presentinvention symbolizing a slightly less general programming language thanthe previous languages, but much more powerful for matchingapplications. Development tool 10 is especially suited for complex,real-time intelligent control applications, and in particular worksextremely well with complex electromechanical systems. By focusing on aparticular problem domain, immense power is gained. Tool 10 provides aframework that helps define a problem so that implementation can beginimmediately. Run-time facilities are provided that solve large parts ofthe problem. Mundane tasks are automated so that complex systemdevelopment is made easier. Development tool 10 may be implemented inany suitable programming language; the JAVA programming language hasbeen found to work well. Tool 10 also provides a graphical userinterface that represents objects graphically and allows a programmer toconnect objects. Such graphical tools that allow graphicalinterconnection between objects are well-known in the art. For example,this aspect of the present invention may be implemented using one of theUML tools such as Rational Rose.

Development tool 10 allows a team to directly implement a solution. Onecan start at a high level developing an overall system plan, yet canbuild a plan using well-defined structures that are sufficiently generalto solve many types of complex control problems. Structures such as dataflow diagrams, state machines, and composite object groups (COGs) areused to build a working system. Although the term “system” is often usedto refer to both the hardware components and the software of a completesolution to a real-time application, as used herein “system” refers tothe user-created software that is eventually loaded onto a real-timecomputer. And although tool 10 is referred to as a development tool, italso provides run-time support for the system that is loaded.

FIG. 2 illustrates an example of a real-time application 50 according toone embodiment of the present invention. In a typical scenario, areal-time system is created on a development station 60 usingdevelopment tool 10 and is then downloaded to a real-time computer 64for execution. Computer 64 then controls the hardware of theapplication. Development station 60 is any suitable computer such as apersonal computer or a work station on which a system is created. Shownsymbolically on development station 60 is development tool 10 of thepresent invention which provides a design environment for the creationof the system. Development tool 10 is used by an individual orindividuals to design the system, implement the design, generatecompiled code, and execute the system code.

Once compiled, the real-time system code including individual compiledcomponents and system diagram files are downloaded over a networkconnection 62 (or any other suitable interface) to real-time computer64. Computer 64 may be any of a wide range of computing devices for usein a real-time system. By way of example, computer 64 may range from asimple printed circuit board up to an IRIX supercomputer.

Real-time computer 64 controls any of a wide variety of hardware, whichin this example is illustrated as a simple robot arm 66. In this simpleexample, computer 64 receives information regarding arm 66 via sensors68 and controls arm 66 using actuators 70. Any of a wide variety ofsensors and/or actuators may be used and are well-known in the art.Examples of sensors include analog-to-digital converters, encoders, andforce sensors. Examples of actuators include motor control cards,digital-to-analog converters, solenoids, and valve controllers.

Furthermore, computer 64 may communicate with any of a wide variety ofother hardware devices for the purpose of operating the real-timeapplication. By way of example, computer 64 also receives informationfrom a vision device 72. Other devices include part conveyors,end-effector devices (e.g. grippers), user input panels, part feeders,etc.

Although only a simple example specific to robotics is provided, thoseof skill in the art will appreciate that development tool 10 may be usedwith a wide variety of real-time applications that are much morecomplex.

FIG. 3 illustrates symbolically the makeup of real-time computer 64. Inthis simple example, at a low level computer 64 includes hardware 80such as a CPU and other electronic circuitry for operation of thecomputer. Any suitable run-time operating system 82 is present inhardware 80 and facilitates operation of the overall real-timeapplication. By way of example, run-time operating system 82 may be anoperating system such as VxWorks from Wind River Systems of Alameda,Calif. Run-time engine 84 is software that executes the user real-timesystem allowing control of the application hardware devices. Engine 84loads system code 62 from station 60 and allows the system code to run.System code reads sensors 68, writes to actuators 70, and in generaloversees execution of the real-time application. Although it is possiblefor system code 62 to be loaded as one large object directly ontooperating system 82, it is preferable that code 62 be loaded asindividual objects onto run-time engine 84 as will be explained below.

Components

Preferably, tool 10 allows an application programmer to graphicallyconnect components in order to build up a diagram representing anintelligent control system. It would be possible, however, forembodiments of the present invention to be implemented without agraphical interface, although one is preferable. In a general sense,components are the pieces or parts representing physical and/or logicalentities that make up a control application. For example, a componentmay represent a controller, a state machine, a trajectory generator, asubsystem, etc.

In a preferred embodiment of the invention, components are implementedas objects according to the class-instance object-oriented programmingmodel. Other programming models such as the object programming model andthe object prototype model may also be used. Objects may be implementedin any suitable programming language, and the C++ programming languagehas been found to work well.

Component Types

In one embodiment of the present invention, components are objectshaving a graphical representation and include the following: atomiccomponents (ATCs); data flow components (DFCs); state transitioncomponents (STCs); interface components (IFCs); finite state machinecomponents (FSMs); and composite object groups (COGs). The first fourtypes of components are primitive components in that they areimplemented directly in code, while the last two components arecomposite components in that they may be represented using other typesof components.

Each type of component is described in more detail below. In general, asobjects, each component has the capability to include attributes (datavalues) and methods (its “interface”). An interface of an objectincludes the attributes of that object or its “pins.” Some componentsdivide attributes into input pins, output pins, and reference pins. Aninput pin is a value needed by a component to execute. An output pin isa value output by a component to another component. A reference pin is avalue associated with a component that is relatively stable, such as again for a controller or a parameter that is always available. Referencepins are well-suited for constant values for a component such asfloating point values, hardwired addresses, strings, etc. In general, apin of a component is a data type that is a connection to the worldoutside the component. Methods may be divided into methods that thecomponent “provides” (implements) and those that the component “uses”(invokes).

Atomic Components

Atomic components are objects that are directly implemented in C++ codeand are the lowest level of granularity of all the components. The roleof an atomic component is to provide generic utility functions orservices to other components within a diagram. In effect, an atomiccomponent extends the capabilities of the diagram in which it iscontained, a diagram that otherwise would not have any user-defined C++code associated with it. For example, atomic components may be insertedinto a composite object group or state machine diagram to extend thecapabilities of that diagram. Preferably, each atomic component has atleast one method that can be called by other components. This method canbe programmed to perform any function that the programmer desires.

An atomic component may also be created by using existing or legacycode. A programmer first uses an interface editor to describe theinterface for the atomic component (i.e., methods it implements, and/ordata it uses) and then supplies the actual code to implement the methodfor the atomic component. The existing code may be simply copied overinto the new atomic component, or if it is a large legacy system, theatomic component may call the legacy code to implement its methods.

Data Flow Components

FIG. 4 illustrates symbolically a data flow component 300. A data flowcomponent is one example of an atomic component that is used to buildthe physical parts of the control system. Data flow components performcontrol, data acquisition, motion generation, signal processing andother electromechanical functions. As such, a data flow componentimplements cyclic (or sampled-data) processing within a control system.Examples of real-world components that may be modeled using a data flowcomponent are: filters, trajectory generators, controllers, matrixoperators, and most any mathematical function that takes inputs andcalculates outputs. Non-mathematical components may also be modeled.

Data flow component 300 includes a component name 302 that indicates thetype of real world component being modeled. Each data flow component 300has an “On Execute” method 304 that is executed automatically everysample period and any number of other methods 306. Preferably, the OnExecute method is a custom method written by a programmer for performinga particular function. In the example of FIG. 14, the trajectorygenerator data flow component uses its On Execute method to calculate avalue for X(desired). The data flow run-time engine will call the OnExecute method of each data flow component every clock cycle. The OnExecute method then reads values from its input pins 308, any referencepins 312, and calculates values for output pins 310 using an appropriatemethod.

Input pins 308 and output pins 310 are important for scheduling of theexecution of the data flow component. In one embodiment of theinvention, the On Execute method may not run until all input pin valuesare available, and its output pin values may not be used until its OnExecute method has executed. An application programmer connects anynumber of data flow components (along with other components if desired)to create a data flow diagram that forms a portion of the controlsystem. Advantageously, data flow components are objects havingtraditional methods and attributes, yet also provide real-timesampled-data processing by virtue of the On Execute method of each dataflow component. Furthermore, the explicit definition of input pins andoutput pins allow a programmer to specifically define which data valuesmust be available before the component executes, and which output valueswill be available after the method executes.

As will be described below, the run-time engine will use the specifiedinput and output pins to perform sorting of all data flow components todecide in which order they are to be executed. Data values not intendedto be used for sorting—or are both input and output values—may bedefined as reference pins 312. Each data flow component may alsoimplement other methods 306 to provide specific functionality. Theseother methods may be called automatically by the run-time engine inresponse to well-defined events during operation of the system.

State Transition Components

FIG. 5 illustrates symbolically a state transition component 350. Statetransition components are atomic components that are used to definesequencing, to process logic, and to provide the “what to do” strategyneeded by the control system. In general, state transition componentsprovide the actions to be taken by a state machine in response tostimuli or events. Preferably, a state transition component is onlyinserted into a state machine component.

State transition component 350 has a component name 352 and an OnExecute method 354. The On Execute method 354 will be called by thestate machine run-time engine when a corresponding event occurs as willbe explained below. Component 350 may include any number of othermethods 356 and also includes any number of pins 358; pins are datavalues either provided by the state transition component or that aremade available to it.

State transition component 350 may be associated with any of a varietyof events within a state machine. The On Execute method 354 provides anaction to be taken based upon a current state of a state machine and anevent that occurs. By way of example, FIG. 14 illustrates state machine202 that makes use of state transition components. When the event “Pickup” is received while in state 220, state transition component “Look” isactivated and its On Execute method will execute. In this simpleexample, the On Execute method of state transition component “Look” willimplement a method that causes a vision system of the robot to beginlooking for the item to pick up. Note that the events “Not found” and“Done” are not associated with any state transition components,presumably because no specific action need be taken when those eventsoccur. The event “Found”, which triggers a transition from state 222 tostate 224, has an associated state transition component “Set goal” whichcalls the “Set goal” method of the trajectory generator component. FIGS.6A and 6B illustrate in greater detail how a method call occurs.

Also included in a state transition component are user-defined returncodes 359. A user may define any return code to be returned by thecomponent's On Execute method. In this example, possible return codesinclude “OK”, “Fail”, and “Error.” An OK return code might indicate thatthe On Execute method has executed successfully, while a Fail codeindicates the method has failed to achieve its intended purpose. AnError code indicates an error detected while the method is executing.Advantageously, a programmer may define any number of return codes, oneof which is returned by the On Execute method. One benefit is that thestate machine run-time engine may then use a return code to controlbranching based upon a particular event. For example, when an eventoccurs triggering a particular transition, the execution of theassociated state transition component might return one of many returncodes. Based upon this return code, the run-time engine then decides towhich state to branch. State diagrams are simplified because an extrastate is not needed to serve as a decision point. The decision making isperformed by the run-time engine using the return code and the statemachine component definition. Further details on the state machinecomponent and the state machine run-time engine are provided below.

Alternative Component Implementation

An alternate implementation is a single type of “primitive” componentthat is directly implemented in C++ code. Whether it is used as an“Atomic Component,” a “Data Flow Component” or a “State TransitionComponent” is simply an attribute of the primitive component. Oneadvantage of this approach is the ability to reuse the same coderegardless of whether the component is used within a data flow or statemachine diagram. (An advantage of the previously describedimplementation is that for each type of behavior of a component, thereexists an explicitly named component.)

For example, consider the situation in which a DFC is already written toadd two matrices. To create an STC that also adds two matrices, the userhas to duplicate the code. In this alternate implementation where thesame component that adds two matrices can be used as a DFC or STC, theuser writes the code once. The data flow engine calls the On Execute andOn State Update methods of the component, and the finite state machineengine calls the On Transition method of the component. (The On Executemethod of a state transition component may be renamed “On Transition” toavoid confusion.)

Component Integration

Advantageously, the data flow, state transition and state machinecomponents are all implemented as objects according to any suitableobject-oriented programming model. Such implementation as objectsgreatly facilitates making interconnections, system design and codereusability. For example, any of the On Execute method, methods 356 andpins 358 of component 350 may be connected to any data flow component orother component in a system diagram. For example, any of the methods maycall another method in a data flow component, and conversely a method ofa data flow component may call one of the methods 356 in a statetransition component. Additionally, any of pins 358 may be connected toan input pin of a data flow component in order to provide data to thatcomponent; conversely, an output pin of a data flow component mayprovide a data value to one of pins 358 of state transition component350. In this fashion, the present invention provides integration betweenthe sampled-data processing world of data flow components in a data flowdiagram, and the event processing world of a state machine.

FIGS. 6A, 6B and 6C illustrate in greater detail how state transitioncomponent Set Goal of FIG. 14 performs a particular action in responseto an event. FIG. 6A shows symbolically state transition component SetGoal 380 in communication with data flow component Trajectory Generator382. Component 380 includes its On Execute method 384 which is showngraphically via arrow 386 as implementing a call to the Set Goal method388 of component 382.

FIG. 6B illustrates in greater detail how On Execute method 384 of statetransition component 380 calls a method of a data flow component. Method384 shows in very simple pseudo code that the On Execute method includesa simple call to the “Do Set Goal” method (bubble 385) of its owncomponent 380. Arrow 386 translates the call to Do Set Goal method 385into a call to the Set Goal method 388 of component 382 via bubble 387.This translation is performed by the linking phase of FIG. 20 at runtime.

FIG. 6C illustrates in greater detail how Set Goal method 388 of dataflow component 382 calls an internal Compute Trajectory method toperform the actual work of computing a new trajectory to the specifiedgoal position. Method 388 shows in very simple pseudo code that the SetGoal method includes a simple call to the Compute trajectory method ofTrajectory Generator 382. In this fashion, whenever the On Executemethod 384 of component 380 is executed, it will call the ComputeTrajectory method of Trajectory Generator 382.

The code within Set Goal component 380 does not have specific referencesto Trajectory Generator component 382 (or any other component), makingSet Goal component 380 a much more reusable component. Just byconnecting arrow 386 to another component that provides a Set Goalmethod automatically changes what gets called when On Execute method 384of component 380 is executed, without having to change any code in SetGoal component 380.

State Machine Components

FIG. 7 illustrates symbolically a state machine component 450. Statemachine component 450 is a composite component built graphically withina system diagram that represents a finite state machine. As is known inthe art, a finite state machine uses a state transition diagram todescribe and implement event-driven processing. Component 450 may beimplemented as either a synchronous or asynchronous state machine. Ingeneral, event-driven processing is provided for a composite objectgroup by creating a state machine component and inserting the componentinto the composite object group. In a preferred embodiment of theinvention, creation of a state machine is performed graphically in whichstates, events and state transition components are identified andconnected together. FIGS. 12-14 provide simple examples of state machinecomponents built graphically. A state machine may also be viewed in theatomic sense in that each state of a state machine may itself be a statemachine, thus providing a hierarchy, if desired.

Component 450 includes a state machine name 452. As this component isimplemented as an object, it may also include any number of methods 454as well as input pins 456, output pins 458 and reference pins 460. Eachstate machine component has any number of states 462, 464, 466, etc. Inthis simple example, only details of state 462 are presented. Associatedwith state 462 are any number of transitions 468, 469, etc. A transitionfor a state provides a triggering event that indicates the state machineshould transition to a new state, along with an action to be takenduring that transition. In a preferred embodiment of the invention,transition 468 includes a received event 470, a next state 472 and astate transition component name 474. In operation, when event 470 isreceived, state machine 450 transitions from state 462 to next state 472and also provides an action to occur during that transition.

Advantageously, the present invention provides an action to occur duringtransitions by way of state transition components. In this example,state transition component 474 is executed during transition 468. Morespecifically, the On Execute method of this state transition componentwill be called when transition 468 occurs. It should be appreciated thatany number of state transition components may be associated with aparticular transition, and that more than one event may be associatedwith a transition. In this example, the programmer of component 450 hasprovided specific state transitions 476-482 to occur based upon thereturn code from state transition component 474. These return codes mayvery well override a transition to next state 472. For example, basedupon a return code of “OK,” state machine 450 transitions to state1.When a “Fail” return code is received, the state machine transitions tostate4. Other return codes may produce transitions to other states. Aspecial return code “Any” provides a transition to state5 if any otherreturn code is received other than those codes 476-480. Advantageously,such a state machine component definition provides decision makingcontrol through the use of state transition components. As will beexplained below, the state machine run-time engine will perform atransition for the state machine based upon the resulting return code.

Interface Components

FIG. 8 illustrates symbolically an interface component 400. An interfacecomponent represents a commonly used interface that is reusable. Byrepresenting a common interface as an object-implemented component, thepresent invention provides an interface that can be reused to simplify asystem design. For example, certain sets of data and function callsalways appear together. These sets of data and function calls are goodcandidates for creating new interface components. Other good candidatesare interfaces to general classes of equipment, instrumentation, ordevices: a power supply interface, a pressure valve interface, a sunsensor interface, an XY stage interface, a motion generator interface,etc.

For instance, a system may have many different power supplies, withdifferent power ratings, turn on/turn off sequences, etc. Nevertheless,these differences may be isolated with a single well-designed powersupply interface component. Each power supply implementation will bespecific to the actual underlying hardware. For example, the turnon/turn off procedure for large power supplies often involves a sequenceof relays that must be thrown in addition to safety checks. A singlepower supply interface component may be used as a standard in a systemfor all power supply implementations. Such a common reusable interfacecomponent simplifies system design and such a system using thatinterface component will be able to use any power supply implementation.

In one embodiment of the invention, an interface component is agraphical representation of the interface of an object. For example, ifan object has associated with it two methods and three data values, atraditional approach would be to attach five graphical lines to theobject to represent these two methods and three data values. Aninterface component is a single icon that represents the connection ofthese two methods and three data values and has a single connection fromit to another object. Once an interface has been defined for aparticular object, an interface component may be created that representsthis interface and the interface component may be reused on similartypes of objects. An interface component may be defined for, and usedwith, any component within the system.

Interface component 400 includes a component name 402, a list 404 of themethods provided by the component to which the interface attaches, and alist 406 of the methods that will be used (i.e., called) by thecomponent to which the interface is attached. Also included are theinput pins 408 indicating data values to be input to the component towhich the interface is attached, and output pins indicating data valuesto be output. Reference pins 412 indicate reference data values used bythe component to which the interface component is attached. In apreferred embodiment of the invention, an interface component isrepresented graphically.

One should distinguish an interface component 400 from the interface toany type of component. The interface component is a reusable combinationof pins and methods implemented as an object; instances may be createdof each interface component. The interface to a component is simply agroup of pins and methods, specific to that component. In fact, theinterface to a component may contain interface components in addition tospecific pins and methods.

Thus, an interface component may be specified as part of the interfaceto another component. When so specified, the instance of the interfacecomponent is said to be “attached” to the component. For instance, adata flow component might have simple numeric inputs for “currentposition” and “desired position.” If an interface component containingpins for “limit” and a method “enable” is attached as well, then thisdata flow component will have access to all three inputs (currentposition, desired position, limit) as well as to the method “enable”.Thus the data flow component easily gets access to all the pins andmethods that the interface component contains.

Composite Object Group (COG) Components

FIG. 9 illustrates symbolically a composite object group (COG) component500. A COG is a composite component that is built graphically usingdevelopment tool 10 in the process of producing a system diagram 136. Infact, the final system diagram 136 is itself a COG. A COG encapsulatesboth sampled-data elements and event-driven elements into a singleobject, so that a COG can be used to model physical entities in asystem. Although a COG may be built using code without the benefit of agraphical user interface, in a preferred embodiment of the presentinvention each COG is built graphically. Examples of COGs being builtgraphically are shown in FIGS. 12-14.

Externally, a COG is viewed as a graphical component with a set ofdefined methods and pins (its interface) that connect with othercomponents. Internally, a COG is a hierarchical diagram that containsmany types of components. Because a component within a COG can also be aCOG, this hierarchy can be used to subdivide system modelshierarchically into finer, more manageable pieces, and to group a set ofcomponents into a reusable unit.

COG 500 includes a component name 502. The OnExecute method 504 of COG500 will execute when COG 500 is scheduled for execution by the run-timeengine. It in turn executes all the OnExecute methods of the data flowcomponents and sub-COGs contained in COG 500. In one embodiment of theinvention, COGs and the components within them are scheduled forexecution in a recursive manner. For example, starting with thetop-level COG, its constituent components (which may be other COGs, dataflow components, etc.) are sorted into a dependency order and schedulefor execution in that order. Once that level has been sorted, the COGswithin that level are then analyzed to determine a sorted order for thecomponents that they contain. This sorting by dependency continues tothe lowest level. In this fashion, all COGs and data flow components ofa system are sorted by their dependency. An example of how data flowcomponents in particular may be scheduled and executed is provided belowin FIGS. 21 and 22.

As this component is implemented as an object, it has an interface thatmay include any number of other methods 506 as well as input pins 508,output pins 510 and reference pins 512. The interface for a COG listsnot only the methods that a COG implements or “provides,” but also themethods that a COG “uses,” i.e., those methods provided by othercomponents. An input pin is a value needed by a COG to run. An outputpin is a value output by a COG to another component. A reference pin isa value associated with a COG that is relatively stable. Advantageously,pins of one COG connected to pins of another COG pass datainstantaneously through the system. A COG need not wait for a method tobe called to receive the value for an input pin, nor need to call amethod to output a value on an output pin. As soon as the data isavailable at a pin it is there to be used by the appropriate COG.

Also included within COG 500 are any number of atomic components 520,data flow components 522, state machine components 524 and othercomposite object groups 526. In this fashion, each COG can representhierarchically the organization of a particular application. In apreferred embodiment, these components 520-526 are interconnected withgraphical interconnections 528 using a graphical user interface. Theseinterconnections define how data flows between components and whichmethods of certain components are called by methods of other components.For example, FIG. 14 shows interconnections 226, 230 and 232.

The sampled-data processing portion of a COG is built as aninterconnected set of data flow components 522 and other COGs 526. Thisset of data flow components and COGs forms a data flow diagram. Eachcomponent within the data flow diagram represents a block of code thatwill be executed. Each component may use input data, generate outputdata, or do both. The input/output dependencies of the data flow diagramare used to specify how data flows through the system. Preferably, thedata flow executes at every sample period of the system. Theevent-driven processing portion of the COG is represented by any numberof state machines 524. As previously described, each state machineprovides states, events, transitions and actions to be executed uponeach transition. In this fashion, a COG advantageously provides acomprehensive building block for intelligent control systems.

Control System Creation Overview

FIGS. 10-13 present different view points on the creation of a controlsystem. These figures provide a high level discussion, further detailsare provided below in the flowcharts of FIGS. 18-23.

User Roles

FIG. 10 illustrates graphically a programming process 100 and the rolesthat various individuals may play in creating a control system. Acomponent programmer 102 uses any suitable editor to create atomic, dataflow and state transition components 106. Programmer 102 definesinterfaces for these components and writes code to implement the methodsof these components. Preferably, programmer 102 is proficient in alanguage such as C++. In a similar fashion, interface programmer 108uses any suitable editor to create interface components 112. Interfacecomponents 112 are objects that define a reusable interface. Programmer108 defines the methods and attributes for each interface. Although areusable interface component may be desirable, they are optional.

Domain engineer 114 uses previously created components 106 and 112 tocreate any number of composite object groups (COGs) 118. Preferably,domain engineer 114 uses graphical development tool 10. Domain engineer114 may also use existing state machine components and COGs and maydefine other components in the creation of COGs 118. Once COGs 118 havebeen created, systems integrator 120 uses development tool 10 to producesubsystem modules and to integrate these subsystem modules into a finalcontrol system in the form of system diagram 136. Finally, the system isloaded onto a real-time computer to control the application in question.Of course, these roles may be performed by the same individual.

Programming Process

FIG. 11A illustrates a programming process 130 for producing a real-timeintelligent control system. Interface definition tool 131 representssymbolically an initial step in which interfaces for desired componentsare created. Tool 131 is used by a programmer to define an interface foreach component desired to be used in the system. It should be noted thattool 131 is used to assist in the creation of components that aprogrammer needs that do not already exist. Other components that aprogrammer will use in developing a system may already have been definedand implemented, and be represented in repository 135.

Repository 135 is any suitable database on a computer for storingcomponents and their associated collection of files that define them.Repository 135 is preferably implemented in a hierarchical directorystructure and is described in greater detail in FIG. 11B.

Types of components for which specific interfaces may be defined includeatomic, data flow, state transition, and state machine components aswell as composite object groups. The definition of an interface for anobject is well-known to those of skill in the art and generally includesdefining the attributes (referred to as “pins” herein) of an object andthe methods that it provides and uses. By way of example, FIGS. 15-17illustrate interfaces for various components of FIG. 14. Although thepreferred implementation uses a graphical tool to capture interfaces, itis similar to the manual method that those skilled in the art utilizewith a text editor.

Primitive Component Creation

Tool 131 results in the formation of an interface file (also termed a“definition file”) for each component defined. The interface filedefined for each component is stored in repository 135 in associationwith that particular component. In one embodiment, interface files arenamed after the component to which they correspond. For example, a COGhas a “.cog” interface file, a state machine has an “.fsm” file, a dataflow component has a “.dfc” file, a state transition component a “.stc”file, an atomic component a “.atc” file, an interface component a “.ifc”file, etc. An interface file provides interface information for itscomponent such as inputs and outputs, method names, etc. Otherinformation may also be stored in an interface file. For example, the“.cog” and “.fsm” interface files corresponding to COGs and finite statemachine (FSM) components also contain an indication of to which mode theCOG or FSM belongs, to which executable image the COG or FSM belongs,and to which thread the COG or FSM has been assigned. Modes, executablesand threads are described in more detail below in the section onmapping.

Once an interface 134 has been defined using tool 131, a suitable codegenerator is used to produce an automatically generated source code file132 that contains code to instantiate and use the component at run-time.In one embodiment, a class definition is generated that has fields foreach data value (pin) and/or method defined for the component.Automatically generated methods include access methods, initializationhooks and status methods. The code generator also automaticallygenerates dummy functions (stubs) 138 used by a programmer to fill inthe methods that the component implements. Specific types of componentshave “standard” stub functions. For example, data flow components havean OnExecute function, a state update function, functions that arecalled when the execution starts and stops, mode change functions andmore.

The user may edit the stubs file 138 to produce a user-edited sourcefile 139. In one embodiment, a suitable compiler compiles theautomatically-generated and the user-edited source code into compiledobjects. These compiled objects are linked together into a singlecompiled object 133 for each component. This compiled code object file133 for an individual component is stored in repository 135 inassociation with the defined component. The object file is loaded duringsystem initialization and linked with other component objects on thereal-time computer to form the complete executable system.

The user-edited source code can also be processed by a documentgenerator, which creates documentation files 139 a in a format suitablefor human viewing. In one embodiment, these are HTML-format filesviewable with a browser. The documentation files are also stored in therepository 135.

Composite (Diagram) Component Creation

Using a suitable graphical user interface of development tool 10, adomain engineer uses interface files 134 stored within repository 135 toproduce a system diagram 136 that represents the intelligent controlsystem. Although it is contemplated that the present invention may beimplemented without the benefit of a graphical user interface, it ispreferred to use one. In a preferred embodiment, each component definedby a particular interface file is represented by a unique graphical iconwithin system diagram 136. The domain engineer is able to browserepository 135 picking and choosing those components he or she needs tocreate system diagram 136. The system diagram is saved as a systemdiagram file 137 (for instance a COG or a state machine), and storedwithin the repository. In addition to the diagram definition, thediagram file also contains interface information similar to theinterface files generated for primitive components.

The graphical connections 528 of FIG. 9 between components used insystem diagram 136 represent instances of data or interface objects. Theuser also creates a diagram data file 137 a associated with the systemdiagram file that indicates data storage allocation and initial valuesfor the data object instances specified in the diagram 136. Forinstance, the data file might indicate that a 3-by-1 floating-pointmatrix is required to hold the data indicated by a line marked“ToolOffset”, and that the initial values should be [4.0, 2.7, 0.0]. Theuser also creates a diagram documentation file 137 b that providesdocumentation for the diagram. In one embodiment, it is a human-readableHTML file that has user notes.

For example, FIG. 15 illustrates the interface for a trajectorygenerator. In a preferred embodiment, this interface (and the trajectorygenerator itself) is represented as graphical icon 204 of FIG. 14 inwhich a solid line represents a data value of the component and in whichcircles or “bubbles” attached to lines represent methods of a component.In one convention, an incoming arrow attached to a bubble representsgraphically a method that a component provides, while a bubble with anoutgoing arrow represents graphically a method that a component uses. Inthis fashion, a domain engineer may quickly and easily connectcomponents in a graphical manner. For example, output pins of one dataflow component are connected graphically to input pins of another dataflow component. Also, methods that a component calls are connectedgraphically via a line to a corresponding component that provides thatparticular method. As shown in the simple example of FIG. 14, a varietyof components may be connected graphically to produce a composite objectgroup 260. In a hierarchical fashion, composite object groups may belinked together to form a larger diagram and the final system diagram136 is referred to as the top-level composite object group.

Preferably, there is a diagram file created for each state machinecomponent and for each COG of system diagram 136. Each of these diagramfiles is a text file that has a list of the components included in thediagram, a list of the connections between the components and anindication of which connections are connected to each component. Ingeneral, each diagram file represents textually the graphicalrepresentation of one level in the design hierarchy. Alternatively, adiagram file need not be a text file, but can be of any format.

For a COG, its diagram file indicates which components are connected towhich others. Using FIG. 14 as an example, the diagram file for COG 260would indicate that state machine 202, trajectory generator 204, and PDcontroller 206 are connected to one another as shown. Likewise, adiagram file for a state machine component also indicates how itsinternal components are connected together. For example, in FIG. 14, thediagram file for state machine 202 would indicate that the “Pickup”stimulus received while in state “Idle” 220 executes the “Look”transition routine and make the state “Look for Item” 222.

Based upon this graphical creation of a final system diagram 136 usinglower level components, the various diagram files and system diagramfile 137 are loaded into repository 135. Files 137 a and 137 b are alsoloaded. Once system diagram 136 has been created and the diagram fileshave been loaded into repository 135, the intelligent control system isready to be loaded into real-time computer 64 to begin execution of thereal-time application. Such loading and execution will be described ingreater detail in FIGS. 18-23.

Repository

FIG. 11B illustrates in greater detail an embodiment for repository 135.Repository 135 may be implemented in any suitable database or directorystructure and preferably stores all components available to a domainengineer for creating a system diagram 136. Components may have arrivedin repository 135 by way of interface definition tool 131 or they mayhave been predefined and supplied by a vendor or third party. In oneembodiment of the invention, repository 135 includes interfacecomponents 142, data flow components 143, state transition components144, state machine components 145, and composite object groups 146. Inactuality, repository 135 may contain any number of data flow components(for example) that have different names and functions. For example, FIG.14 illustrates two data flow components, namely trajectory generator 204and PD controller 206, each of which may be present within repository135. In a similar fashion, different types of the other components mayalso be present within the repository.

Interface component 142 includes an interface file 134 defined usingtool 131, a source code file 132 produced by the code generator in block130, and a compiled object file 133 available from block 130. Adocumentation file 139 a is also provided from the documentationgenerator in block 130 that contains user notes regarding the component.

Each data flow component 143 includes an interface file 134 definedusing tool 131, a source code file 132 produced by the code generator inblock 130, a user-edited source code file 139 also available from block130, and a compiled object file 133 available from block 130. Adocumentation file 139 a is also provided from the documentationgenerator in block 130.

Each state transition component 144 includes similar types of files ascomponent 143 although the files of course will be different. Each statemachine component 145 includes a diagram file 137 created by tool 10from system diagram 136, and data 137 a and documentation 137 b files.In a similar fashion, each composite object group within repository 135includes a diagram file and data and documentation files.

Methodology

FIG. 12 illustrates a methodology 150 for creating a robot controlsystem. As previously mentioned, COGs are components built from statemachine components and data flow diagrams and are used in the creationof control system using object-oriented techniques. As shown, thismethodology supports top-down object decomposition from right to left,and bottom-up component-based synthesis from left to right. The systemwill be explained from left to right, although design may occur in anyorder.

In this example, data flow component Trajectory 152 is a part of dataflow diagram Arm Control 154 which is used to implement a portion of thesampled-data processing needed for the robot system. State transitioncomponent Open Gripper 156 is used as part of state machine Grasp 158 toperform the action of opening the gripper on the arm. An interfacecomponent Arm Command 160 has been defined to provide an interface toCOG 162 that represents the robot arm. Components 154 and 158 are alsoincluded within COG 162 to provide both sampled-data processing andevent-driven processing.

COG 162 representing the robot arm is itself a part of module 164 (whichitself is also a COG) representing the overall robot that also includesother COGs representing other portions of the robot. In turn, robot 164is part of a greater system, namely work cell 165. Work cell 165 alsoincludes a vision module 166 and a graphical user interface module 167to complete the overall system. Modules 166 and 167 are also COGs, as iscell 165.

FIG. 13 illustrates a methodology 170 for creating an aerospace system170. The following description progresses from right to left in atop-down fashion although design may occur using a combination oftop-down and bottom-up design. System 172 includes a graphical userinterface 174, an Orbital Maneuvering System (OMS) 176 and apressurization control system known as the Forward Reaction ControlSystem (FRCS) 178. System 172 and elements 174-178 are preferably allimplemented as COGs.

FRCS module 178 includes numerous COGs that are interconnected andenable FRCS 178 to perform its function. FRCS 178 includes by way ofexample a COG tank 180 that represents a tank within the system. Aninterface component 182 has been defined to represent the interfacebetween tank 180 and the other COGs within FRCS 178. Tank 180 includes adata flow diagram 184 that represents the tank fill control, and a statemachine 186 that represents the pressure sequencer of the tank. Tankfill control diagram 184 includes a data flow component filter 188 thatis used to implement the data flow. Pressure sequencer 186 includesstate transition component Open Valve 190 that performs the function ofopening a valve when a transition is made from one state to another.

Thus, a methodology has been briefly presented that provides opportunityfor both bottom-up and top-down design. Working from left to rightutilizes functional programming in a bottom-up design. Working fromright to left uses object-oriented concepts in a top-down design.Advantageously, the present invention supports both concepts. Inpractice, the design process for a control system is an iterativeapplication of both approaches. Advantageously, COG 162 and COG 180 bothsupport sampled-data processing through use of data flow components anddiagrams, as well as event-driven processing through the use of statemachines and state transition components.

Robot Arm Controller Example

FIG. 14 illustrates a very simplistic robot arm controller 200 thatprovides a simple example of a composite object group (COG) and ofvarious interfaces. Details are also shown in FIGS. 6A, 6B and 6C. Inthis simplistic example, robot arm controller 200 controls a robot armwhich is directed to look for an item, move its arm to the item, andthen grasp the item. Robot arm controller 200 includes state machine 202that determines the state of the robot arm, a trajectory generator dataflow component 204 that generates a desired trajectory for the robotarm, and a PD controller data flow component 206 that provides controlto a motor driver circuit 208 that moves the arm. Sensors 210 includeany type of vision or similar sensors for determining the position ofthe robot arm and delivering an actual position signal 212 to PDcontroller 206. In this simple example, the value X(actual) 212 is asimple matrix that represents the X and Y position of the robot arm.

State machine 202 has three states. State 220 is an idle state in whichthe robot arm is not moving. When a Pick-up command is received, thestate machine moves to state 222 in which it looks for the item to pickup. During this transition, the state transition component Look isexecuted that directs a vision system to look for the item. Thisdirection is implemented as a method call through the method connection236 to the Vision Look method 237 of sensors 210. If the item is notfound, then the state machine returns to idle state 220. No action isexecuted during this transition. If the item is found, however, a Foundevent occurs and a transition to Moving state 224 occurs. During thistransition, the state machine calls a state transition component namedSet Goal. In turn, the On Execute method of this component executes andcalls the Set Goal method 227 of component 204 through method connection226. Once the state machine receives the Done event, it enters idlestate 220.

Set Goal method 226 is a method provided by trajectory generator 204that is called by the state transition component associated with thetransition from state 222 to 224. The Set Goal method takes as a singleparameter the value X(new) which is the new location to which the robotarm should move to pick up the item. Done method 232 is a method calledby trajectory generator 204 that is implemented by state machine 202 andcauses the Done event to occur.

Trajectory generator 204 receives the request to implement the Set Goalmethod and calculates a trajectory of points to move the robot arm fromits current location to the X(new) location. For each sample period inthe system (i.e., each cycle), the trajectory generator outputs a valueX(desired) which is a single one of the trajectory of points. In thisfashion, the trajectory generator incrementally moves the robot arm frompoint-to-point to gradually move it to the location X(new).

PD controller 206 receives input value X(desired) 230 and input valueX(actual) 212, and gain 240. Gain 240 is a reference value that is moreor less constant. PD controller 206 calculates a control signal 250 bymultiplying the gain by the difference between X(desired) and X(actual).Control signal 250 is delivered to motor driver circuit 208 which movesthe robot arm an appropriate amount. After a series of incrementalmovements based upon a trajectory of points output from trajectorygenerator 204, the robot arm will have moved from its original locationto the location X(new).

In a more abstract sense, state machine 202, trajectory generator 204,and PD controller 206 may be thought of as a more general intelligentcontroller 260 that is capable of controlling the motion of virtuallyanything based upon input from sensors 210. In this sense, intelligentcontroller 260 is a composite object group (COG) as it forms a higherlever intelligent controller made up of the components 202, 204 and 206.

FIG. 15 is a textual representation of an interface 260 for trajectorygenerator 204. As shown, interface 260 indicates that the trajectorygenerator provides the Set Goal method, uses the Done method, and has anoutput pin X(desired). FIG. 16 is a textual representation of aninterface 270 for PD controller 206. As shown, interface 270 indicatesthat the PD controller neither provides nor uses methods, but includes avariety of pins. Included are input pins X(desired) and X(actual),reference pin Gain, and output pin Control. FIG. 17 is a textualrepresentation of an interface 280 for intelligent controller COG 260.As shown, interface 280 indicates that COG 260 provides the Pick Upmethod, uses the Do Look method 235 and includes various pins. Includedare an input pin X(actual), reference pin Gain, and an output pinControl.

Mapping

Many system resources are mapped throughout a hierarchical system. Theinvention includes techniques for mapping system resources through thehierarchy of COGs. The techniques are presented in terms of the COGstructure, but are applicable to any hierarchical composition ofexecutable programs. The present invention provides the ability to mapthe modes of a system (i.e., choose which components of system will runin which mode), to map to an executable image (i.e., choose whichcomponents will be part of which executable image), and to map tothreads of a processor (i.e., choose on which threads which componentswill run).

Mode Mapping

Most complex systems require different operating modes. Each operatingmode can be represented in a system diagram 136 as a list of activecomponents. An active primitive component will execute when it isnormally scheduled. An inactive component skips its execution, and isthus turned “off”. Thus, modes advantageously allow the system to selectsets of components to execute under user or program control.

Prior art “Simulink” from The Mathworks of Natick Massachusetts and“SystemBuild” of Integrated Systems Inc. of Sunnyvale Calif. solve thisproblem with “enable” control signals that appear as lines on thediagram. When the block is to be enabled, the signal line is activated.This solution, however, results in a large number of control lines and“switch blocks” to manage them. It is difficult to understand whichparts of the diagram will execute in different modes.

Furthermore, many complex systems often radically change modes ofoperation during execution. The designs of these systems may fail toconsider the wide-ranging effects of these mode changes and “run out ofsteam” due to the complexity of the branches and switch blocks required.A fundamentally new approach would be desirable.

Advantageously, the current invention allows designers to define modesvisually as shown in FIG. 24 by simply clicking on the components to beactivated. The modes are displayed on development tool 10 byhighlighting the active components. This makes modal operation mucheasier to understand. In general, a mode corresponds to a set of activecomponents. By defining different modes, a real-time system can switchbetween different codes paths easily and quickly. Mode switching mayalso be performed under the direction of the event-driven part of a COG,thus allowing the COG to react to events by changing operating modesautomatically.

For instance, in FIG. 24, the system of seven data flow components mayhave two operating modes. The first mode may require the five componentsJoint Sensors 580, Vision Sensor 550, Object Trajectory 555, VisualServo 560, and Robot Interface 570, and allows the system to followobjects based on vision input. The second mode may require Joint Sensors580, Joint Trajectory 575, PID Joint Control 565 and Robot Interface550, and lets the system move to arbitrary joint positions. These modesare advantageously displayed for easy understanding in development tool10.

Moreover, the modes are then given names, and referred to by name. Thisadvantageously provides a level of abstraction between the modedefinition and mode selection, insulating higher-level programs fromimplementation details. For instance, the above modes may be named“Vision Control” and “Joint Control”.

The present invention advantageously allows users to define modes ofcomplex systems by selecting a mode for each sub-system by name. Thusfor example, in FIG. 25, an overall system mode for COG 593 may bedefined by choosing a mode from Command COG 585 (one of “Calibrate”,“Home”, “Normal”, or “Increment”), a mode from Control COG 590 (from“Slow”, “Fast”, or “Accurate”), and a mode from Motor COG (from “Off”,“Safe”, or “Normal”). Sensors 587 are any suitable sensors that may beeither on or off. System modes could be defined for COG 593 such as:

Mode Command Control Motor Startup Calibrate Slow Safe LargeMotionNormal Fast Normal FineMotion Increment Accurate Normal Safe Home SlowSafe Test Normal Fast Off

With these modes, the system can easily be used to start motions, slew,perform fine operations, and more. Each change switches many componentsdeep in the hierarchy, but it is presented as an intuitive, named changeat the top level.

In one embodiment, modes for subsystems are selected by choosing from alist presented when clicking on the icon representing the subsystem. Ofcourse, there are many possible means of selecting named modes. In oneembodiment, a mode menu is available for the application component(highest level) or a COG. The menu contains commands to activate anddisplay the modes defined for that component. The activate commandactivates a mode once the name of the mode is specified. The displaycommand displays graphically (or textually) the implementation of thatmode, i.e., those components that are active for that mode. The user isthus able to easily see and initiate modes. In one embodiment, theinterface file (“.cog” file) for each COG keeps track of which of itsincluded components are associated with which modes defined upon theCOG. Other tracking mechanisms are also possible.

Modes may be defined differently for different types of components. Forexample, it is mentioned above that a given set of components may beactive for a certain named mode. For a COG, then, a certain named modeof that COG indicates which components within it will be active, or willbe “running” in that named mode. Because a COG may have many modesdefined, a COG does not have a simple “on” mode. A COG, however, doeshave one mode that is the default mode. The default mode may be assignedto any mode. If not, the default mode of a COG means that all containedDFCs and FSMs are “on”, and that each contained COG is in its defaultmode. For the simple, primitive components such as atomic components,data flow components, and state transition components, each has simplyeither an “on” or an “off” mode.

In general, each operating mode is represented in a diagram as a list ofactive data flow (DFC), COG and FSM components. An active or “on” DFC orCOG means that it will run at every sample period; an active FSM meansthat it is processing stimuli. “Off” for a DFC or COG means that that itwill not run anything at each sample period. An FSM that is “off” willnot process any stimuli. The tool allows a user to change modes—the listof active components—at run-time without shutting down the application.Activating a mode of a COG activates all the components of the COG thatare part of that mode, while also causing the other components in theCOG to be deactivated.

In one specific embodiment of the invention, each mode is represented byan object. I.e., an object is instantiated that corresponds to a certainmode. This mode object encapsulates a variety of information includingthe knowledge of which contained components are part of the mode. Forexample, if a given COG has two modes, each is represented by an objectand each keeps track of which internal COG, state machine, data flowcomponent, etc. belong to that mode. Further, each mode object hasmethod “activate” that allows that mode to function to the exclusivityof the other modes. For example, once the “activate” method is calledfor a “calibrate” mode of a COG that also has a “run” mode, the methodthen functions to only activate those components that belong to the“calibrate” mode; the other components are not activated.

Switching between modes is also allowed. Each COG further has a methodcalled “change mode” that takes as a parameter the mode to which thesystem should be switched. For example, should the user wish to switchthe system from the “calibrate” mode to the “run” mode, the “changemode” method is called. The effect of the change mode method is to callthe “activate” method for the “run” mode, and to deactivate thosecomponents that are associated with the “calibrate” mode. Modes may bechanged (i.e., changing the list of active components) at run timewithout shutting down the application.

Thread and Habitat Mapping

Other system resources are also mapped through the hierarchy. In a dataflow system, sets of components often run at different rates ofoperation. For instance, the controller and the motor output may have torun at 500 Hz (every 2 milliseconds), while the collision detection mayonly need to run at 2 Hz (twice a second). Of course, in a real system,hundreds of components may have to execute at specific rates. Schedulingthese sets of components requires mapping components to operating systemthreads. As is known in the art, a thread is a process that runs on aprocessor. There may be more than one thread running on one processor.

The present invention provides a mechanism for mapping threads tocomponents. Advantageously, the present invention defines an objectcalled a “habitat” that encapsulates a thread and the list of componentsthat are to run at a certain rate. Thus, assigning a component to ahabitat object results in the component being assigned to a particularthread and rate. A habitat object represents an execution environmentfor a set of components. This environment includes the specification ofthread priorities, sample rates, and even CPU identification in amultiprocessor system. Using multiple habitats allows for multi-ratesystems and multi-threaded applications. Advantageously, the habitatobject (including its rate) is defined at a high level and then mappeddown through the hierarchy to individual components.

Data flow systems (data flow components and COGs) associated with thesame habitat run at the same sample rate using a single thread ofexecution. All finite state machines (FSMs) associated with the samehabitat execute in a single thread, but each maintains a separatelogical event queue for stimuli. In addition, each FSM is allowed accessto operating-system level resources through its habitat. These resourcesinclude: a thread of control that runs the FSM engine; a message queuethat holds incoming stimuli; and a periodic timer for checking numericstimuli. Within a single application, multiple FSMs may share the samehabitat, thereby allowing a single thread to manage multiple independentstate machines.

At the top level of a system diagram, a user defines one or more actualphysical habitats (or “local” habitats) that corresponds to actualrun-time operating-system threads that are available for the entireapplication. The user also assigns actual parameters—priorities, rates,CPU, etc.—to these local habitats. At lower levels of the hierarchy ofcomponents—within COGs and FSMs—the user defines logical habitatplaceholders known as “mapped” habitats. These include logical rates foreach component. Then using a suitable user interface, the user mapsthese logical habitats (and logical rates) to actual physical habitats(and actual rates) at the highest level.

Advantageously, the present invention allows users to define theselogical rates for components. A COG, or a data flow component, canutilize one or more logical rates. To map executable resources to theCOG, the user assigns a habitat from the enclosing COG to each rate ineach sub-COG or component. In this manner, the present inventionadvantageously allows fine control over how many threads are running inthe system. In one embodiment, the interface file (“.cog” file) for eachCOG keeps track of which of its included components are associated withwhich threads (including with which rates) assigned to the COG. Othertracking mechanisms are also possible.

In one embodiment, each local (or physical) habitat defines a pair ofthreads. One thread is for the sampled-data portion of the system, andthe other for the event-driven portion. Parameters for the sampled-dataportion of the habitat include sample rate, CPU, priority, stack size,task options, etc. Parameters for the event-driven portion of thehabitat include FSM rate, CPU, priority, stack size, task options, queuecapacity, etc. Each application or system has one local habitat, butseveral habitats may be present in multi-rate applications.

The process of mapping habitats (including rates) consists of defining amap at each hierarchical level of a system. The following discussionillustrates such mapping using only the rate parameter; mapping of otherparameters and habitats may occur in a similar fashion. First, theactual rates available within a real-time system are defined at thehighest level of the system (the top-level COG or “application” COG).Next, each component contained in this highest level has its logicalrates mapped to the actual rates defined. Thus, for each DFC, COG andFSM, its defined logical rates are mapped (or assigned) to the actualrates available within the system. This procedure continues in arecursive manner. Thus, for each COG in the hierarchy, the logical ratesof its contained components are mapped to the logical rates for the COG.More than one logical rate of a contained component may be bound to thesame container rate, thus forcing components designed to be capable ofrunning at different rates to run at a single rate. This situation maybe required because of limited system resources. Finally, for aprimitive data flow component, each sample rate is implemented with C++code. For simple applications, each container component has a defaultlogical rate; every component placed into the container is mapped to thecontainers default rate. Therefore, for simpler single-rateapplications, rates need not be mapped explicitly in order to run theapplication.

For example, in FIG. 26, ParentCOG 1000 (the top-level COG) containsthree components: COG 1002, COG 1004, and a data flow component 1006.Cog 1002 utilizes three logical rates, called rate1, rate2, and rate3.Cog 1004 and Dataflow 1006 each support only one logical rate, rate1 aswell. In one embodiment, the logical rate names of peer COGs (1002, 1004and 1006) are not related implicitly, although such an implementation ispossible. Parent COG 1000 defines two habitats A and B, each providing a10 Hz rate and a 100 Hz rate, respectively. In other words, two possiblethreads of execution are represented by habitats A and B. The otherparameters provided by these habitats are not shown.

Because there are three logical rates required overall, yet only twoactual rates provided, two of the logical rates will have to double up.If there had been three habitats provided (presumably with differentrates), each of rate1, rate2 and rate3 would be assigned to a differentrate. To map the parent's actual habitat rates, “10 Hz” and “100 Hz” toits sub-COGs, the user simply assigns habitat to logical rates by name.For example, habitat A is assigned to rate1 and rate2, and habitat B isassigned to rate3. This assignment may be done graphically by clickingon the rates in each COG which provides a menu of choices (oralternatively by clicking on the habitats), or may be done manually by aprogrammer in code. Were any of components 1002 or 1004 to have sub-COGsor other components, the logical rates of these contained componentswould then in turn be assigned to the logical rates of COGs 1002 and1004. Thus, the actual rates of 10 Hz and 100 Hz are mapped throughoutthe hierarchy.

FIG. 27 provides an example of such mapping. A top-level parent COG 1010(alternatively called the “application”) defines two habitats A and Bhaving two actual rates of execution, 10 Hz and 100 Hz, respectively.Contained within parent COG 1010 is COG 1014 that defines two logicalrates, rate a and rate b. Included therein is COG 1018 using rate c, COG1022 using rate d, and COG 1024 using rate e and rate f. Included withinCOG 1024 are data flow components 1026, 1030 and 1034 using rate g, rateh and rate i, respectively.

Parent COG 1010 may have been constructed in a top-down fashion, abottom-up fashion, or by using a combination of the two. At some point,the user will map rates either from top-down or from bottom-up.Considering the top-down approach, the user first maps rate a to habitatA (an actual rate of 10 Hz), and maps rate b to habitat B (an actualrate of 100 Hz). Next, rate c and rate d are both mapped to rate a.Within COG 1024, rate e is mapped to rate a, and rate f is mapped torate b. Finally, rate g and rate i are mapped to rate e, while rate h ismapped to rate f. Of course, different mappings are possible. In thisfashion, the actual rates of 10 Hz and 100 Hz are assigned to componentsthroughout the hierarchy.

Executable Program Mapping

In a complex system, users sometimes wish to build multiple executableprograms from a single diagram or set of diagrams. Advantageously, thepresent invention allows users to assign executable programs throughoutthe hierarchy. As with modes and habitats, executable assignment is byname. In general, from a single system diagram, the user may builddifferent executable programs, each consisting of a different subset ofcomponents that make up the application for the desired executable. Theprocess of selecting the subset of components involves defining anexecutable by name and hierarchical mappings through the system diagram,much like the mapping process for habitats and rates described above.The resulting executable contains only those components that are neededto implement that executable program.

For example, in FIG. 28, controller COG 1040 has two different possibleimplementations. Control component 1070 can be used with the actualhardware components SensorDriver 1060 and MotorDriver 1090, or with thesimulated components InputSimulator 1050 and OutputSimulator 1080. Inputvalue Desired Position 1055 is used in either implementation. These twoimplementations are built into different executable programs. Forexample, the actual hardware drivers may only exist on an embeddedreal-time system, while the user may wish to run the simulated versionon his desktop workstation. The present invention allows the user todefine a “hardware” executable for the actual hardware case, and a“simulated” executable for the simulation case.

To define these implementations, placeholder executable names areidentified in COG 1040 and components are assigned to them. Thisassignment of components to executable names is similar to the waycomponents are assigned to rates as described above. The mapping ofexecutable may be accomplished in the same manner. In this simpleexample, components 1055, 1060, 1070 and 1090 are assigned to the formalparameter “real”, indicating they are part of an executable for realhardware, and components 1055, 1050, 1070 and 1080 are assigned to theformal parameter “sim”, indicating they are part of an executable for asimulation.

From the next level up shown in FIG. 29, these options appear asselections in the executable mapping for controller COG 1110. Forexample, COG 1040 defines two executables “hardware” and “software”.They will run on actual hardware and a simulation computer,respectively. The formal parameter “real” and its assigned componentsare mapped to the “hardware” executable, while the formal parameter“sim” and its assigned components are mapped to the “simulation”executable. Of course, an executable can be mapped throughout amulti-level hierarchy of components in much the same way that rates aremapped. If the other components MotionCommand 1100 and Monitor 1120 areincluded in both executable programs, the system can advantageouslygenerate both a hardware version with drivers or a simulation versionwith simulated hardware from a single diagram. The user is then freedfrom having to design different systems to produce different executableprograms. A simple choice at a high level can produce the desiredexecutable program.

In another example, consider a control system to be run in both a UNIXsimulation world and on a real-time system. The user is able to definetwo different executable programs by name at a high level. Bothexecutables will contain the same controller COGs, but the UNIXexecutable will include a set of component definitions that implements asimulation of the plant, while the real-time system will include a setof component definitions that contains the hardware device drivers. Thistechnique maximizes the reuse of component definitions and guaranteesthat—in this example—the controller is the same for both systems.

Leveraging a single design into many executable programs provides twomain benefits: concurrent operation and platform accommodation.Concurrent operation is provided because individual executable programsderived from one system diagram may execute simultaneously on differentprocessors. Platform accommodation is provided because an executable maybe defined for a specific set of hardware or architecture, allowing asingle system diagram to generate executables than can run on otherwiseincompatible platforms.

Platform accommodation allows simulating a design before implementingit. In this scenario, a system diagram would have two components foreach hardware unit. One represents the hardware device driver; the othersimulates the hardware. Thus, the simulation executable contains thesimulation components; the implementation executable contains thehardware components. Both executables contain the hardware-independentcomponents, thus ensuring that the simulated and implementationexecutables mirror each other as closely as possible.

A typical use is to define executables for multiple target platforms.For example, an executable called “host” might be created, and anotherone called “vx” that correspond to applications that will run on ahost-development platform (UNIX or Windows NT) or VxWorks, respectively.All relevant components of the system diagram are mapped to eachexecutable. Each executable, however, includes a differentplatform-dependent clock. For instance, the vx system includes anauxiliary clock component, while the host system includes a defaultclock component.

In one embodiment of the invention, mapping of executables may proceedas follows. With respect to FIG. 28, first the formal parameters names“real” and “sim” are created to serve as placeholders for two differenttypes of executables. Next, components are assigned to each parametereither by clicking on a component and naming the parameter to which itis assigned, or by starting from a parameter name, and then choosingincluded components by searching through a directory. Internally, tool10 makes a notation in the system diagram file indicating that aparticular COG or component is to be included with a particular type ofexecutable. Alternatively, in another embodiment, the interface file(“.cog” file) for each COG keeps track of which of its includedcomponents are associated with which executables defined upon the COG.Finally, once COG 1040 is complete and implemented as part of FIG. 29,the user defines two executables “hardware” and “simulated” to which aremapped “real” and “sim”, respectively. When it come time to run anapplication, an image is built for either the “hardware” or “simulated”executable and it is loaded onto the appropriate computer.

In a variation on this embodiment, tool 10 provides for each COG(including the top-level) two predefined flags named “Included” and“Excluded.” The Included flag for a COG means that the COG itself andall components within its hierarchy are included within the executablefor its container COG. This results in the top-level Included flagincluding all components in the entire system diagram—all the way downthe containment hierarchy. The Excluded flag for a COG means that theCOG itself and all components within its hierarchy are excluded from theexecutable for its container COG. For example, control COG 1070 of FIG.28 may be flagged Included to indicate that it forms a part of anyexecutable for Controller COG 1040.

Detailed Flowcharts for System Creation and Execution

Overall System Creation

FIG. 18 is a flowchart describing one embodiment of the life cycle foran intelligent control system. Of course, there are other aspects to thelife cycle of a control system such as initial design, iteration,testing, maintenance, etc., although these aspects are not shown in thisflowchart. In step 602, components needed for the implementation of thesystem are created. These components include any of the componentspreviously discussed herein. These components may be created by avendor, a third party, or by a programmer who is building the controlsystem. Of course, creation of components may take place in advance ofthe actual building of the system, or may take place in parallel withstep 606 as the system is being created and a need for a particularcomponent is realized. In this sense, bottom-up design (i.e., creationof components) may alternate with top-down design (high level blockspecification). In a preferred embodiment of the invention, creation ofindividual components occurs as described in FIGS. 10, 11A and 11B andthe components created include those illustrated in FIGS. 4-9 anddiscussed herein. Other variations on these components and other typesmay also be created.

In step 604 each created component and its interface is compiledindividually and the results are stored in repository 135. Step 604 maybe performed as previously described in blocks 131-133 of FIG. 11A. Inparticular, the components compiled are atomic, interface, data flow andstate transition components, and the result of step 604 is a source codefile, a user-edited source code file, a documentation and a compiledcode file for each component. Step 604 may take place all at once, or acompilation of components may occur mixed in with step 606 as aprogrammer creates a system.

In step 606 a domain engineer creates a high level system diagram 136using a graphical user interface of development tool 10 as has beenbriefly described previously in FIGS. 2 and 9-14. A preferred embodimentfor step 606 is presented in greater detail below in FIG. 19, althoughthe creation of a system may take many forms. The result of step 606 isa system diagram 136, diagram files 137 and a data file for each statemachine component and composite object group (COG) created during theprocess.

Once a system diagram 136 has been created, in step 608 the compiledcomponents are loaded onto the real-time computer. In one embodiment,the compiled code (or object) files for each atomic, interface, dataflow and state transition component are loaded from repository 135 ontoreal-time computer 64. These compiled code files provide executable codefor each of these components. The individual component objects have beenlinked together with a typical link editor phase of a compiler toresolve symbols. However, data and method links between these componentsspecified by the diagrams have yet to be completed. Links betweencomponents are provided in the diagram files for each state machine andCOG defined during step 606. Step 610 loads these diagram files fromrepository 135 onto real-time computer 64. Linking phase 612 connectscomponents in accordance with the diagram files. This phase will bediscussed in greater detail below in FIG. 20.

Initialization phase 614 provides initialization for data flow and statemachine components and is described below in FIG. 21. In step 616 theuser of the system initiates system execution so that the system maybegin performing the control application for which it has been designed.

During system execution, numerous processes may be running concurrently.In a preferred embodiment of the invention, one or more data flowrun-time engines 618, along with one or more state machine run-timeengines 620 are executing in parallel in order to provide sampled-dataprocessing and event-driven processing, respectively, for the controlsystem. These engines are discussed in greater detail below in FIGS. 22and 23. Concurrently, the control system may accept user input 622,which may dictate a change in the course of action for the system. Thisuser input includes starting and stopping the engines, statusmonitoring, changing parameters, etc.

Creating System Diagrams

FIG. 19 is a flowchart describing one embodiment for thecreate-system-diagram step 606 of FIG. 18. It will be appreciated bythose skilled in the art that the design, implementation and test of anintelligent control system may be performed in a wide variety ofmanners. By way of example, FIG. 19 presents one suitable designmethodology that works well with the present invention, although otherdesign methodologies may work well also. Advantageously, this designmethodology uses a combination of top-down and bottom-up design usingcomponent object groups (COGs) and components to provide a fast andintuitive system design. The entire process of creating a system diagramis iterative and the steps shown are not necessarily performed insequential order. In fact, it is most likely that steps may be performedin combination as the domain engineer goes back and forth betweentop-down and bottom-up design.

Defining COGs

In step 640 top-down design is used to identify subsystems within thecontrol system that will be modeled as composite object groups (COGs).This step typically creates a hierarchy of COGs through a top-downdecomposition of the system into logical object models. Advantageously,it is easiest to map each logical object model to a physical object or aset of physical objects in the system: a power subsystem, a chemicalhandling subsystem, a vacuum subsystem, a work cell, a robot, etc. Anobject model can also model software: a user interface, a motionplanner, etc. Each logical object model is then decomposed further intosmaller objects: a power supply, a gas flow regulator, a pump, a robotjoint, a collision avoidance algorithm, etc.

Once a hierarchy of logical object models has been created, a COG iscreated to represent each of the object models. Preferably, this is donegraphically using development tool 10 in which an icon represents a COG.A top-level COG is created to represent the final control system. NewCOGs are then created for each of the lower level object models andthese are inserted into the top-level COG. Creation of COGs asplaceholders for each object model continues in this hierarchicalfashion until the lowest level is reached. COGs may be created in thisstep merely as placeholders and do not need any implementation detailsat this point. Further down the hierarchy of COGs, it may be possible touse an existing COG or component from the repository 135. Components arealso reused at lower levels during bottom-up implementation. Examples ofa top-down design combined with bottom-up implementation using ahierarchy of COGs are shown in FIGS. 12 and 13.

COG Interfaces

In step 642, an interface is defined for each COG in the hierarchycreated. Examples of an interface for a COG are shown in FIGS. 9 and 17.Although an interface for a COG may be defined using code, is itpreferable to define the interface graphically. During this step, thedomain engineer analyzes what data and data types will be needed by theCOG and defines appropriate input pins for the COG. Data to be producedby the COG is identified and corresponding output pins are defined forthe COG. Additionally, any reference data needed or used for the COG isidentified and a reference pin is defined upon the COG for each suchreference data value. The domain engineer also analyzes each COG todetermine which methods (or commands) will be provided (or supported) bythe COG. For each such method provided by the COG, the engineer definesa name for each such method and provides a graphical notation on the COGindicating that it is a method that the COG provides. In a similarfashion, the engineer determines which methods or functionality each COGwill need to access in other components. The engineer then defines amethod name upon the COG corresponding to a method that the COG willneed to call. This allows the COG to issue commands to other components.

As interfaces for COGs are defined, the role of each COG within thesystem as well as its capabilities in functionality become more refined.Step 642 is iterative in that COGs throughout the hierarchy may need tobe revisited and their interfaces redefined. During this step it ispossible not to make connections between COGs. Connections between COGscan made at any time. When a connection is made on the graphical diagram136, it is entered into the COG diagram file 137. The diagram file has alist of graphical interconnections 528. During the linking phase 680,the run-time engine loads the diagram file, reads the list ofinterconnections, and performs the connections from pins and bubbles inthe COG object to data objects, as described below with reference toFIG. 20.

Using Reusable Interface Components

As an optional step, the domain engineer and/or interface programmerdetermine if the system design will benefit by grouping often used dataand commands into a reusable interface component. Creation of aninterface component is discussed above with reference to FIG. 8. Asanother option, the domain engineer may wish to identify data typesand/or create needed data types to encapsulate a set of data or toguarantee type safety. Use of data types is a tradeoff between typesafety and reusability and is an implementation detail appreciated bythose of skill in the art.

Dividing into Data Flow and State Machines

Step 644 begins the implementation phase of development and is oftenreferred to as bottom-up design. Because the entire creation of a systemdiagram is iterative, this step may very well begin before the entireobject model hierarchy had been determined in step 640. Furthermore, thebeginning of this implementation phase may in turn cause additionalhierarchies to be exposed, thus triggering further top-down designbeginning again in step 640.

In step 644 each COG is divided conceptually into sampled-data andevent-driven processing portions, although there may not necessarilyboth be present for a given COG. For example, higher level COGs tend tobe more event-driven as they respond only to commands and rare events.These COGs may not have a sampled-data portion. Lower level COGs,however, often perform more sampled-data processing as they continuallymonitor, filter, control, or otherwise process physical systems. TheseCOGs may not necessarily include an event-driven processing portion.Other COGs may very well have a combination of both sampled-data andevent-driven processing portions. Once each COG has been separatedconceptually into sampled-data and event-driven processing portions,each of these portions is then implemented using components provided bythe present invention.

Data Flow

Step 646 defines data flow and produces a data flow diagram for thesampled-data portion of a COG. To build a data flow diagram for a COGthe domain engineer preferably looks for COGs and/or data flowcomponents in the repository that already perform pieces of theprocessing need. If necessary, new COGs and/or data flow components arecreated at this time to provide functionality required. Next, the reusedand newly-defined COGs and data flow components are connectedgraphically to perform the processing required. As each controlapplication is unique, the creation of a suitable data flow diagram isdependent on each situation. Those skilled in the art will appreciatehow to connect input and output pins of COGs and data flow components toprocess data within the particular COG. A simple example of a data flowdiagram is shown in FIG. 14 in which data flow components 204 and 206accept inputs, process data, and finally produce an output controlsignal 250 for controlling an application. Of course, much more complexdata flow diagrams are possible.

State Machines

In step 648, the event-driven processing for a COG is created bydefining and implementing state machines necessary for each COG.Event-driven processing provides reactive behavior for each COG and isimplemented by using state machine components that are either alreadyexisting in the repository or that are created at this point in time bythe domain engineer. Each COG may include one or may state machines, ornone at all.

As previously discussed, each state machine includes a state transitiondiagram, the methods (or command set) that the state machine provides,and a list of methods that the state machine uses (that are connected tocomponents that implement those methods). Also included are input andreference pins for connecting to sensors that the state machine canmonitor to trigger state transitions. Output pins are connected to othercomponents as appropriate.

To design the state transition diagram for each state machine component,the states of the system are first determined and then added to thestate machine. The domain engineer determines how the state machine willrespond to events by defining these events and the transitions that willoccur from one state to another. The events (stimuli) that occur may bediscrete events, may be conditional statements using system parametersand constant values, or may even be Boolean expressions involving systemparameters. As previously noted, a given state machine may in fact be ahierarchy of state machines in that a given state may itself representanother state machine component. For complicated sequences oftransitions or for common sequences of transitions, new state machinesmay be created.

Once transitions have been defined, actions are determined that are tobe taken at each transition. Preexisting state transition components areused to perform these actions, and new state transition components maybe created if necessary. These state transition components are assignedto the appropriate transition in the state machine. Next, branchingbased upon possible return codes is determined and is added to the statemachine. Once the necessary state machine components have been fullydefined, they are also connected to appropriate data flow components andto COGs as necessary.

Subsystem Test

In step 650 each individual COG, state machine component, or higherlevel subsystem is tested. This is an optional step although is itpreferred to test subsystems before system integration. Testingindividual subsystems may be performed in a similar fashion as fortesting and running the complete system. In step 652 the previouslyimplemented and tested subsystems are integrated together into thecomplete system. During this step, the high level COGs from eachsubsystem are linked together graphically through their interfaces in anappropriate manner. In step 654 the complete system diagram is testedand readied for loading and execution.

Execution Environment

Once the system is built, it is also necessary to define the executionenvironment in which the system will run upon the real-time computer. Ofcourse, as there is a wide range of real-time computers, the definitionof an execution environment for each computer will vary widely. Ingeneral, though, the user provides values for parameters of run-timeoperating system 82 and real-time computer 64. By way of example, theuser defines a clock rate, defines tasks, priorities, stack sizes, taskoptions particular to an operating system, parameters for run-timemodules such as data monitors, debug settings, buffer sizes, etc.

In a preferred embodiment of the invention, a special executionenvironment component (termed the “habitat” object above) is providedthat allows a user to graphically define the run-time operating systemparameters that the system will use. Also provided is a clock componentthat allows a user to graphically determine a clock rate for the system.In general, this execution environment component allows the user to mapthe needs of the created system to the real-time computer resources. Ofcourse, mapping of these resources may be performed in many differentways and will depend upon the actual real-time computer that is beingused. Resources may be mapped manually by giving commands, programming ascript file, setting parameters, etc.

Linking

FIG. 20 is a flowchart describing one embodiment for the linking phasestep 612 of FIG. 18. In general, the linking phase links togetherpreviously compiled and loaded components to one another using diagramfiles that have been created in step 606. In step 606 the domainengineer has created a hierarchical system diagram 136 that includes atop-level COG (or state machine component) and any number of other lowerlevel COGs, state machines and other components. As shown in FIG. 11Band explained earlier, each of these COGs 146 or state machinescomponents 145 has an associated diagram file.

In step 670 the top-level diagram file is identified. This top-leveldiagram file represents the COG at the highest level, i.e., the completesystem. Alternatively, this diagram file may represent any number ofCOGs and/or state machines interconnected with other components. In step672 this top-level diagram file is loaded into real-time computer 64. Instep 674 the data file 137 a associated with this top-level diagram isalso loaded. The data file contains definitions of and initial valuesfor any data objects created at the top level.

As previously noted, the user provides values for operation systemparameters to define the execution environment in which the system willrun. In a preferred embodiment of the invention, an executionenvironment component is used to graphically define these parameters anda clock component is used to set a clock rate. In step 676 the executionenvironment component and the clock component are instantiated. Thisinstantiation spawns operating system threads that will execute therun-time engines. The thread parameters are taken from the executionenvironment parameters. In an alternative embodiment, a graphicalrepresentation of an environment component is not required; threads andparameters may be defined manually.

The flowchart now begins a recursive process in which the top-leveldiagram file and the diagram files within it are processed recursively.Of course, a programming technique other than recursion may be used toprocess the hierarchy of COGs. In step 678 the current diagram file (forthe first pass this will be the top-level diagram file) is identifiedand the COGs and/or state machines in this diagram file are identifiedalong with any other components.

For each COG and/or state machine identified, its diagram and data filesare loaded in step 680. Each of these pairs of files will then beprocessed as described below. As previously noted, a diagram file for aCOG or state machine includes a list of components included, a list ofconnections, and how the components are connected together. In step 682each atomic, data flow or state transition component found in thecurrent diagram file is instantiated. In step 684 each interface object,and each data object (e.g. data matrix) in the data file is alsoinstantiated.

In step 686 the newly-instantiated data and interface objects are linkedto the newly instantiated components so that they connect the componentsas specified in the current diagram file. The graphical connections 528between components used in system diagram 136 represent instances ofdata or interface objects. The list of connections is stored in diagramfile 137. The linking process provides for each pin and bubble connectorfor each component a pointer to the data or interface object connectedto the pin. Providing pins on different components pointers to the samedata object connects the components. For instance, the data read by anencoder sensor may be placed into a data matrix object called “Position”through the encoder sensor's “output” pin. A controller component mayhave its “x” input pin connected to the same “Position” matrix. Theencoder and controller components would then be connected. Eachinterface component object is in effect a bundle of pins and methodsthat the connected components can access.

Once the diagram file for the current COG or state machine has beenprocessed, step 688 determines if there are more COGs and/or statemachines represented in the current diagram file. If not, this indicatesthat the lowest level of the system hierarchy has been reached, no moreprocessing is needed and the linking phase ends. If, however, there aremore COGs or state machines in the diagram file, the loop begins againat step 678 in order to load the diagram file for the COG or statemachine in order to process and to link the components within it.

Initialization

FIG. 21 is a flowchart describing one embodiment for the implementationof initialization phase step 614 of FIG. 18. The initialization phasereadies the data flow diagram portion of the system and also preparesthe state machines of the system for execution.

The run-time engine has built a list of data flow components in thelinking stage that are identified in step 702. In step 704 this list ofdata flow components are sorted by their dependencies. In other words,the interconnections between data flow components are identified and thecomponents are sorted to satisfy input-output relationships. Forexample, FIG. 14 shows data flow components 204 and 206. In this simpleexample, component 206 depends upon component 204 because it receivesinput 230 from that component and can not execute its particularfunction and until it receives that input value. Thus, component 204would be placed before component 206 in the sorted list because it mustexecute first in order to provide a value to component 206.

Once the data flow components have been sorted, in step 706 the initialsystem mode is activated, causing the default set of data flowcomponents to be scheduled for execution.

The linking phase also builds a list of state machine components. Instep 708, the engine traverses the list, and all of the state machinecomponents in the system are initialized. Initialization includesattaching to a habitat, thus setting the machine to receive stimuli fromthe stimulus queue. The initial state is set, and all persistent stimuliare set to known values.

Finally, the list of all components is traversed, and each is given achance to perform user-defined initialization, such as resetting state,allocating memory, or other activities.

Data Flow Execution

FIG. 22 is a flowchart describing one embodiment for data flow run-timeengine execution of FIG. 18. The data flow run-time engine isresponsible for executing each data flow component at the proper timeand in proper order so as to produce the correct data flow through thesystem. As indicated in step 740, each data flow component will beprocessed in turn based upon the sorted list created in step 706.

Step 742 checks whether the component is enabled in the current mode ofthe system. If not, control moves to step 746 as execution only proceedsif the component is enabled in the current mode. If so, the OnExecutemethod of the data flow component is called and executed in step 744.The result of this execution for a particular data flow component isthat its input pin values and reference pins are read and its outputpins values are then calculated according to the user-defined OnExecutemethod. Step 746 checks whether the last component has been reached andtransfers control to step 748 when done.

A similar process in steps 748-754 lets each component perform anyafter-the-sample update activities. The two-step structure allowsminimal delay during the first part of the execution and is known in theart. Step 752 calls an “OnStateUpdate” method to allow the component toexecute any non-time critical code—calculations that do not dependdirectly on sensor values just acquired or that do not generate outputthat must be written to actuators, for example. Specific optimizationsmay be performed to skip components that do not implement On StateUpdate or On Execute methods.

Of course, this execution loop is repeated for every data flow habitatin the system. Each habitat may run at a different rate and on adifferent priority in a thread. On a multiprocessor system, each habitatmay run in a different processor. Each habitat calls the componentsmapped to it as described in FIGS. 26 and 27.

The data flow run-time engine performs many other functions, such ascalling component methods when the system starts and stops sampling,checking for errors, and switching modes of execution.

State Machine Execution

FIG. 23 is a flowchart describing one embodiment of the state machinerun-time engine of FIG. 18. The state machine run-time engine isresponsible for the operation of each of the state machines within thecontrol system.

In step 770 an event is received by the system. As will be appreciatedby those skilled in the art, an event can be any input from a sensor oruser that effects operation of the control system. By way of example,typical classes of events include commands, alarms, time-out conditions,sensor value changes, failures and more. The event is queued to the FSMhabitat event queue in step 772. When it is queued, the intended statemachine is saved with it. Steps 770 and 772 may be handled by differentthreads of execution than handle the following steps.

The FSM habitat thread is waiting for events in its queue. In step 774the event is taken from the queue. In 776, the engine determines whichstate machine should process the event. The engine determines thelowest-hierarchical-level (innermost) state of the FSM in step 778. Instep 780, the engine matches the received event with a transition in thecurrent level of the state machine. For example, FIG. 14 shows events“Pick up”, “Found”, “Not Found”, and “Done”, each associated with adifferent transition in state machine 202.

FIG. 7 also shows an event 470 associated with transition 468 in ageneric state machine component. If the event matches the transition instep 782, then in step 786 the state transition component that isassociated with the matched transition is executed. In general, thisstep is equivalent to any suitable action or function occurring upon thereceipt of its matching event. In a preferred embodiment of theinvention, step 786 is performed by executing the OnExecute method ofthe state transition component associated with the matched transition.For example, FIG. 7 shows a state transition component 474 associatedwith transition 468. Execution of this method may cause a transition toa new state within a state machine or may cause other actions to occur.If the event does not match, then step 784 checks the enclosinghierarchical level and step 785 checks if there are any more levels.This continues until there is a match or error.

There may be many state machine engines in the system, each processingevents from the same or different state machine habitats. State machinesare mapped to habitats as described with reference to FIGS. 26 and 27.

Computer System Embodiment

FIGS. 30 and 31 illustrate a computer system 900 suitable forimplementing embodiments of the present invention. FIG. 30 shows onepossible physical form of the computer system. Of course, the computersystem may have many physical forms ranging from an integrated circuit,a printed circuit board and a small handheld device up to a huge supercomputer. Computer system 900 includes a monitor 902, a display 904, ahousing 906, a disk drive 908, a keyboard 910 and a mouse 912. Disk 914is a computer-readable medium used to transfer data to and from computersystem 900.

FIG. 31 is an example of a block diagram for computer system 900.Attached to system bus 920 are a wide variety of subsystems.Processor(s) 922 (also referred to as central processing units, or CPUs)are coupled to storage devices including memory 924. Memory 924 includesrandom access memory (RAM) and read-only memory (ROM). As is well knownin the art, ROM acts to transfer data and instructions uni-directionallyto the CPU and RAM is used typically to transfer data and instructionsin a bi-directional manner. Both of these types of memories may includeany suitable of the computer-readable media described below. A fixeddisk 926 is also coupled bi-directionally to CPU 922; it providesadditional data storage capacity and may also include any of thecomputer-readable media described below. Fixed disk 926 may be used tostore programs, data and the like and is typically a secondary storagemedium (such as a hard disk) that is slower than primary storage. Itwill be appreciated that the information retained within fixed disk 926,may, in appropriate cases, be incorporated in standard fashion asvirtual memory in memory 924. Removable disk 914 may take the form ofany of the computer-readable media described below.

CPU 922 is also coupled to a variety of input/output devices such asdisplay 904, keyboard 910, mouse 912 and speakers 930. In general, aninput/output device may be any of: video displays, track balls, mice,keyboards, microphones, touch-sensitive displays, transducer cardreaders, magnetic or paper tape readers, tablets, styluses, voice orhandwriting recognizers, biometrics readers, or other computers. CPU 922optionally may be coupled to another computer or telecommunicationsnetwork using network interface 940. With such a network interface, itis contemplated that the CPU might receive information from the network,or might output information to the network in the course of performingthe above-described method steps. Furthermore, method embodiments of thepresent invention may execute solely upon CPU 922 or may execute over anetwork such as the Internet in conjunction with a remote CPU thatshares a portion of the processing.

In addition, embodiments of the present invention further relate tocomputer storage products with a computer-readable medium that havecomputer code thereon for performing various computer-implementedoperations. The media and computer code may be those specially designedand constructed for the purposes of the present invention, or they maybe of the kind well known and available to those having skill in thecomputer software arts. Examples of computer-readable media include, butare not limited to: magnetic media such as hard disks, floppy disks, andmagnetic tape; optical media such as CD-ROMs and holographic devices;magneto-optical media such as floptical disks; and hardware devices thatare specially configured to store and execute program code, such asapplication-specific integrated circuits (ASICs), programmable logicdevices (PLDs) and ROM and RAM devices. Examples of computer codeinclude machine code, such as produced by a compiler, and filescontaining higher level code that are executed by a computer using aninterpreter.

Although the foregoing invention has been described in some detail forpurposes of clarity of understanding, it will be apparent that certainchanges and modifications may be practiced within the scope of theappended claims. For instance, the invention is applicable to a widevariety of control systems. Also, many types of graphical and/or textualuser interfaces work well with the present invention. Therefore, thedescribed embodiments should be taken as illustrative and notrestrictive, and the invention should not be limited to the detailsgiven herein but should be defined by the following claims and theirfull scope of equivalents.

1. A composite object group (COG) data structure embodied in acomputer-readable medium for building a control system that has a clockcycle, said COG data structure being implemented using object-orientedprogramming and comprising: an interface for passing information to andfrom said COG data structure, said interface passing at least onecontrol signal for controlling an aspect of said control system; a dataflow object arranged to accept input data and to produce output data onsaid clock cycle, said data flow object connected to said interface andproviding sampled-data processing for said control system; and a statemachine object that includes a plurality of states and a plurality oftransitions between said states that are each triggered by an event,said state machine object providing event-driven processing for saidcontrol system and being connected to said data flow object, wherebysaid COG data structure provides both sampled-data and event-drivenprocessing for said control system.
 2. A COG data structure as recitedin claim 1 wherein said control system is an electromechanical controlsystem.
 3. A COG data structure as recited in claim 1 wherein saidcontrol system is a real-time control system.
 4. A COG data structure asrecited in claim 1 further comprising: a state transition objectincluded within said state machine object, said state transition objectbeing associated with one of said transitions and providing an action tobe performed upon said one of said transitions, whereby said statemachine object provides said action for said COG.
 5. A COG datastructure as recited in claim 1 further comprising: an execution methodincluded in said data flow object, said execution method receiving saidinput data from sensors of said control system and calculating saidoutput data.
 6. A COG data structure as recited in claim 1 furthercomprising: connections between said interface, said data flow objectand said state machine object that are represented graphically to a useron a computer screen.
 7. A COG data structure as recited in claim 1further comprising: a plurality of other COG data structures in ahierarchy, said hierarchy modeling said control system.
 8. Acomputer-implemented method of defining a composite object group for usein building a control system, said method comprising: providing aninterface for passing information to and from said composite objectgroup, said interface passing at least one control signal forcontrolling an aspect of said control system; providing a data flowobject that is arranged to accept input data and to produce output dataon a clock cycle of said control system, said data flow object providingsampled-data processing for said electromechanical control system;providing a state machine object that includes a plurality of states,said state machine object providing event-driven processing for saidcontrol system; providing at least one transition between said statesthat is triggered by an event; linking said state machine object to saiddata flow object; and linking said state machine object or said dataflow object to said interface, whereby said composite object groupprovides both sampled-data and event-driven processing for said controlsystem.
 9. A method as recited in claim 8 wherein said control system isan electromechanical control system.
 10. A method as recited in claim 8wherein said control system is a real-time control system.
 11. A methodas recited in claim 8 further comprising: providing a state transitionobject, said state transition object being associated with saidtransition and providing an action to be performed upon transition,whereby said state transition object provides said action for saidcomposite object group.
 12. A method as recited in claim 8 furthercomprising: defining an execution method of said data flow object, saidexecution method receiving said input data from sensors of said controlsystem and calculating said output data.
 13. A method as recited inclaim 8 further comprising: linking said state machine object to saiddata flow object using a graphical user interface; and linking saidstate machine object or said data flow object to said interface using agraphical user interface, whereby said composite object group isrepresented graphically to a user on a computer screen.
 14. A method asrecited in claim 8 further comprising: defining a plurality of othercomposite object group in a hierarchy, said hierarchy modeling saidcontrol system.
 15. The method, as recited in claim 8, furthercomprising: defining a plurality of other composite object groups; andplacing the composite object groups in a hierarchy by placing acomposite object group within another composite object group.
 16. Acontrol system for use on a real-time computer, said control systemcomprising: a system diagram graphically representing components andinterconnections between components, said system diagram including adata flow component arranged to accept input data and to produce outputdata on a clock cycle, said data flow component providing sampled-dataprocessing for said control system, and a state machine component thatincludes a plurality of states and a plurality of transitions betweensaid states that are each triggered by an event, said state machinecomponent providing event-driven processing for said control system; anda database repository storing computer code associated with said systemdiagram and said components, said database repository including a systemdiagram file representing said graphical system diagram, and a compiledcode file for each component including compiled computer code forexecuting the functionality of said each component, whereby said systemdiagram file and said compiled code files of said control system may beloaded onto said real-time computer for execution.
 17. A control systemas recited in claim 16 wherein said control system is anelectromechanical control system.
 18. A control system as recited inclaim 16 wherein said control system is a real-time control system. 19.A control system as recited in claim 16 further comprising: a compositeobject group included in said system diagram, said data flow componentand said state machine component included in said composite objectgroup, whereby said composite object group provides both sampled-dataand event-driven processing for said control system; and a diagram filefor said composite object group included in said database repositoryrepresenting the contents of said composite object group.
 20. The COGdata structure, as recited in claim 1, further comprising a plurality ofother COG data structures, each of the plurality of other COG datastructures, comprising: an interface for passing information to and fromsaid COG data structure, said interface passing at least one controlsignal for controlling an aspect of said control system; a data flowobject arranged to accept input data and to produce output data on saidclock cycle, said data flow object connected to said interface andproviding sampled-data processing for said control system; and a statemachine object that includes a plurality of states and a plurality oftransitions between said states that are each triggered by an event,said state machine object providing event-driven processing for saidcontrol system and being connected to said data flow object, wherebysaid COG data structure provides both sampled-data and event-drivenprocessing for said control system wherein a hierarchy between COG datastructures is defined by allowing one COG data structure to be acomponent within another COG data structure.